Re: Silently corrupted WC?

On Wed, Feb 26, 2014 at 11:24 AM, Tony Sweeney <tsweeney_at_omnifone.com> wrote:
>
>
>> -----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.

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