On Mon, Aug 31, 2009 at 7:15 AM, Akos Maroy<maroy_at_euedge.com> wrote:
[snip]
>> 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.
-John
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2388867
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-08-31 13:55:18 CEST