Hi, I recently ran into an issue with subversion that I don't know if it is a bug or something I'm not understanding, so I figured I'd ask here in case I run into something similar in the future.
I'm running a Jenkins server for some ci-jobs for a project. The server checks out the code from svn, builds and runs etc. Due to some issues at corporate IT, we ran out of disk on the jenkins machine. So the svn update failed as expected. But somehow it modified the .svn-directory in a way so that it thought that the WC was correct even though some files had gotten mangled (some source files were just empty). "svn status" said nothing was wrong and I even did "rm -rf" on the source directory followed by an update which of course just took back the corrupted source files from .svn instead of downloading them from the server. As I misinterpreted the compiler output I had, it took me quite some time to realize my working copy was the root of the problem and not something with compiler versions :) My question is if svn shouldn't catch this with some checksum to warn me that my working copy is not to be trusted? Or could I have had the extreme bad luck to have a collision on such a checksum? It is of course ok that things fail when we run out of disk, but I get scared if svn doesn't detect that the WC is broken. The above happened with a 1.7.3 client. Due to corporate IT, I can't run any more recent version at the moment. BR, Chris
