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

Re: recovering svn repository?

From: John Szakmeister <john_at_szakmeister.net>
Date: Mon, 31 Aug 2009 07:54:22 -0400

On Mon, Aug 31, 2009 at 7:15 AM, Akos Maroy<maroy_at_euedge.com> wrote:
>> However, it has done so to great success, but one issue folks run into
>> often is that the they think it'll fix everything the first time
>> through... and may not.  I've needed to run it upwards of a dozen
>> times on some revs.  However, that also depends on what the actual
>> issue is.  Sometimes, the fix that fsfsverify employs isn't enough,
>> because you have actual data loss in there.
> most probably there is..

Not in my experience. Chances are there isn't any data loss.

>> You could use fsfsverify to truncate the node that's corrupted,
> how?

Examine the -t option (run fsfsverify -h for a list of options). -i
accepts a node identifier... which looks like 1a2.c.3/12345

>> I generally advise folks to fix the broken revision, depending on when
>> it occurred, and because of the fallout that can occur (tags, history,
>> and devs can all be affected).  My schedule has been pretty chaotic,
>> but if you can let me see the broken revision, I've been very
>> successful at recovering them.  If you do have some data loss, but
>> still have access to the corrupted files in their original form
>> (because they were deployed, or because you have diffs in an archive,
>> etc), I've also been able to recover revisions with data loss as well.
>>  It just depends.
> I'm not actually concerned about data loss, as I have the data around to
> replace it with. the problem was that the repository itself got into an
> inconsistent, un-usable state.

I understand. It's not just about data loss though. It's about
preventing future corruption to because truncating a node alters
history, and that violates a fundamental assumption in Subversion.

>> You could try dumping and loading, skipping the bad revision... but
>> that ends up being more problematic than helpful in most cases. :-(
> :(
> I ended up creating a new repository.
> but it seems that subversion is quite ill-equiped to deal with large
> collections of large files..

Again, not in my experience. In fact, I'd say quite the opposite: it
handles large files better than any other VCS I've used.



To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-08-31 13:55:18 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.