On Tue, Feb 25, 2014 at 3:09 PM, Chris <devnullacco...@yahoo.se> wrote: > 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.
Was / is it a native svn client (which one?), or an SVNKit (pure java implementation) version? They can have different behavior in such edge cases. I'd expect an svn client to complain loudly when running out of disk space during update, and to keep complaining as long as the working copy is corrupt. Now, you probably know this, but regardless of whether it is a native client or SVNKit, 1.7.3 is *old* and contains many bugs which were fixed in more recent releases. It's quite possible that you've run into some bug that has long been fixed (feel free to do some digging through the CHANGES log [1] or the issue tracker [2]). Please try to convince your IT department to at least go to the latest 1.7.x version (and if possible to the latest 1.8 version, though that's a bit more involved because it implies you running 'svn upgrade' on each working copy). [1] http://svn.apache.org/repos/asf/subversion/trunk/CHANGES [2] http://subversion.apache.org/reporting-issues.html -- Johan
