> -----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. > > 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). Actually, not for Jenkins it doesn't. It is possible to configure a default local workspace format for Jenkins to any of 1.4 through 1.7 Subversion workspace versions (as of Jenkins version 1.543). Further, unlike native clients, SVNKit is workspace version agnostic; the higher SVNKit versions, on being asked to update an older workspace, fall back internally to the appropriate workspace compatibility code automatically and transparently. Tony. > > [1] http://svn.apache.org/repos/asf/subversion/trunk/CHANGES > [2] http://subversion.apache.org/reporting-issues.html > > -- > Johan > > ______________________________________________________________________ > This email has been scanned by the Symantec Email > Security.cloud service. > For more information please visit > http://www.symanteccloud.com > ______________________________________________________________________ > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2014.0.4335 / Virus Database: 3705/7093 - Release > Date: 02/14/14 Internal Virus Database is out of date. ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________
