On Mon, Dec 05, 2005 at 06:10:17AM -0500, John Szakmeister wrote:
> On Sunday 04 December 2005 11:23, Malcolm Rowe wrote:
> [snip long interesting explanation]
s/explanation/hypothesis/. While I think it's a pretty good one (it
fits the results exactly), I haven't yet got any evidence to back it up.
> 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. :-/
Right, and I can't _replicate_ such a thing either. I've tried injecting
read and write errors into various places during the commit phase,
and all I get back is something like:
svn: Commit failed (details follow):
svn: Can't read file '/home/malcolm/fault-inject/repo2/db/revs/1': Input/output error
and the transaction is deleted.
> 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).
It occurred to me that it is possible that mod_dav_svn is a necessary
part of the reproduction. Though if that is the case, I'm not going to
be able to replicate it, because I don't have Apache installed.
What I think I might do is see if it's possible to create a 'broken'
(ra_local) client that I can persuade to corrupt the repository, then
look at how we can fix the problem in libsvn_fs_fs - we shouldn't really
be depending upon the caller to do the right thing.
> On the flipside, I now have an algorithm for recovering the bad files.
Yes, a partial result, at least.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Wed Dec 7 22:10:50 2005