[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Silently corrupted subversion working copy - is this a bug?

From: Kevin Gadd <kevin.gadd_at_gmail.com>
Date: Tue, 12 May 2009 13:24:43 -0700

Somehow, during the normal course of operation, my working copy got
corrupted. None of the subversion tools I have access to were able to detect
that the working copy was corrupted, and operations like 'svn update' and
'svn revert' all functioned normally and worked correctly with the exception
of the corrupted part of the working copy.

A single subfolder in my repository ended up with a mangled entries file - a
portion of the entries file describing two of the files in the folder (a .js
and a .css file modified in a specific commit) was missing and the text-base
for the missing files were gone, but everything else was there. Diff showed
no other differences between the mangled subfolder and a fresh, valid
checkout; just the entries file and text-base files. Performing any kind of
svn update or svn revert succeeds but does not correct or detect the issue.
I also tried using TortoiseSVN's 'check for local modifications'.

I don't have any theories for how the corruption occurred - I didn't
terminate any svn processes recently, and I know that this folder was in
good condition within the past few days. Deleting the corrupted folder and
then restoring it by performing 'svn update' in the parent folder corrects
the issue.

The fact that the entries file got corrupted isn't particularly worrying to
me; I wouldn't be amazed to discover that killing svn with a ctrl+c or
ctrl+break would do this if my timing was good. However, I was very
surprised to discover that subversion had no way to detect that the file was
corrupted - every indicator available to me claimed I had an up to date
repository, when I actually did not.

Does anyone have any suggestions for steps I can take to further research
this problem? Is this a known issue? Alternately, is there a command I can
use to do an exhaustive integrity check of a repository when I suspect
something like this has occurred?

Ideally I would like to track down the cause of this issue and contribute a
patch if it's something that can be fixed, since I'm fairly certain I've had
this issue before, but I did a new checkout of the repository instead of
digging in deeper the last time. Since I rely on Subversion at work, I want
to be able to trust the integrity of my working copy.

For reference, here's the output from svn status on the mangled working
copy, and svn status on a fresh checkout of the repository:

C:\bad_wc\stage\ui\chrome\filter>svn status -v
             57725 57715 andy .
             57725 57715 andy FilterControlTest.html
             57725 57115 kgadd img
             57725 57115 kgadd img\filter_expanded.png
             57725 57115 kgadd img\filter_collapsed.png

C:\good_wc\stage\ui\chrome\filter>svn status -v
             57723 57715 andy .
             57723 57715 andy FilterControl.js
             57723 57715 andy FilterControlTest.html
             57723 57115 kgadd img
             57723 57115 kgadd img\filter_expanded.png
             57723 57115 kgadd img\filter_collapsed.png
             57723 57715 andy FilterControl.css

Thanks in advance,
-kg

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2220445

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-05-12 22:35:15 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.