On Sunday 04 December 2005 11:23, Malcolm Rowe wrote:
[snip long interesting explanation]
> I'm still not sure why we restarted writing the delta-rep rather than
> abort the transaction, however.
I don't know either. It's really bizarre. I am going to see if I can apply
the same logic to the other corrupted revisions that I have and see if it
lines up. I too am dumb-founded as to why we would attempt to rewrite the
delta instead of aborting the transaction. Looking through the backend code,
I don't see any place where we would attempt such a thing. :-/
> Ah: note that this probably can't be a deterministic problem with the
> svndiff/vdelta code, since we repeated the operation successfully the
> second time around.
Well, I've got a clean version of the corrupted repository, and so far have
been unable to recreate the original corruption. The only thing I haven't
done yet is to use mod_dav_svn to do the commit. I need to set up Apache
locally (I usually just use the davautocheck when developing Subversion).
On the flipside, I now have an algorithm for recovering the bad files. Before
I was rather unsuccessful (and time-limited) so I wasn't able to locate the
repeated block in 2 of the other corrupted revision files that I have. Now,
I can at least locate the two blocks, and with a simple script determine the
actual start and size of the repeated blocks. The result is that we're able
to recover the file contents for anyone who suffers from this sort of
corruption.
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Dec 5 12:12:46 2005