On Wed, Feb 26, 2014 at 11:24 AM, Tony Sweeney <tswee...@omnifone.com> wrote: > > >> -----Original Message----- >> From: Johan Corveleyn [mailto:jcor...@gmail.com] >> Sent: 25 February 2014 22:53 >> To: Chris >> Cc: users@subversion.apache.org >> Subject: Re: Silently corrupted WC? >> >> 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. > > Jenkins uses SVNKit internally. The SVNKit version will depend on the > Jenkins version.
Okay, then I suggest the OP takes this issue to the svnkit mailinglist [1], and / or searches their issue tracker [2]. This may very well be an SVNKit-specific issue. There were some stability problems with the early 1.7.x releases of SVNKit, sometimes the consistency of the database was not guaranteed. [1] http://svnkit.com/support.html [2] http://issues.tmatesoft.com/dashboard -- Johan