Since 4 weeks, we get this error frequently (after 2-3 builds) in the repository:
Uncommitted changes found after reverting working folder ‘C:\BuildServer\Rc\635142ee’. The following 1 paths are listed as uncommitted:
! Care4\Code\CareData\Entities\KitaAttendancesRecord.xml
I’ve resetted it several times, created a new one … it always happens to the same file.
On our workstations everything is fine. The file isn’t new or anything special. I can’t find anything wrong in our repository.
So at this time, we have to reset the repository, so we can start a build. However, resetting lasts very long (3 hours), so this is an annoying workaround.
Any idea how we can get closer to this issue?
We are using 1.7.1.152
Hi Christian,
We’ve seen this before with another user - but never got enough information to work out the cause. The other user had an additional issue with locked files. Are there any other errors in the event log referring to a locked or corrupt repository. Can you check that no other programs (e.g. anti-virus software) are accessing the repository cache folder and might be locking files? Can you also check which version of the SVN client you are running on the Continua CI server?
We would really need to look at a debug log to investigate further. Can you enable debug logging on the server, restart the Continua CI Server service, then reset the repository and wait until the errors occur again before sending a copy of the log file to support@finalbuilder.com. Can you also send details of the repository settings, via screenshots or by downloading a diagnostics report from the event log page?
It’s also interesting that your repository takes so long to reset. Is it a large repository, does it have a lot of large files and/or a lot of branches? What version of the Subversion server are you running?
our repository is without issues, i’ve run a “svnadmin verify” without complains. i cannot see any other programs accessing the cache folder (checked existing file handles). the server runs svn version 1.8.13 (as any other workstation or system).
we do not have large files but many files in Trunk (33.000 and 2000 folders) and we have many branches which are always copies of Trunk. However, branches matching our configured branch pattern count to 30.
Our branch pattern is set “/(Testing/)?(Hauptversionen|Features)/[^/]+/” and the “Match top level branches only” is switched off because of this.
So i think the “/Tags” (a lot more) are ignored (as its configured, too).
i will create a debug log when resetting the repository and i will try to reproduce the situation with the error, so you have both things logged.
Sent you the logs and some more information. However, i fixed it for now (seems to be):
1) Renamed the failing branch to “2015Q4.Bak”
2) Created a new copy of it named “2015Q4”
After the rename, the repository check was alread green. Now i merged something new in the new branch and its still green. So it seems to be gone now.
Maybe the error is in your cache or something like that.