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.
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
Received on 2014-02-25 23:53:34 CET