> -----Original Message-----
> From: Johan Corveleyn [mailto:jcorvel_at_gmail.com]
> Sent: 25 February 2014 22:53
> To: Chris
> Cc: users_at_subversion.apache.org
> Subject: Re: Silently corrupted WC?
>
> On Tue, Feb 25, 2014 at 3:09 PM, Chris
> <devnullaccount_at_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
______________________________________________________________________
Received on 2014-02-26 11:25:51 CET