----- Andrew MacKenzie <email@example.com> wrote:
> > > The commits that have caused the corruption, however, went 'fine'
> from her
> > > standpoint. Though she did have at least one 'failed' attempt
> before it I
> > > think (though not immediately).
> > I don't think this is connection-related at all. There are
> > occurring over the wire, so bad data would get thrown out before it
> > attempted to finalize the revision.
> Hrm. That seems to be the only thing this user has 'different' about her
> though. There's lots of other folks using SVN and nobody has managed to
> corrupt a repo, and she's done it twice!
I suppose the network issue might help present the issue, but it's certainly not the cause of it. Malcome Rowe managed to determine the algorithm behind the corruption, but unfortunately, neither of us have come up with a successful reproduction recipe:
> I'm going to try again this time with my router dropping packets,
> adding delay, etc. (found a program called 'tc' that can do such things).
> It'll probably be fine, but I'll give it a go anyway (at least proving to
> myself that network issues aren't the problem).
> Possibly it's being triggered by Tortoise somehow? My script ran with the
> svn.exe command line client. I'll try more tests with TSVN...
Perhaps, but at the core TSVN is using the Subversion libraries. So it's unlikely that TSVN is what triggers the issue.
> There is push-back on that one, given that BDB doesn't seem terribly
> well supported anymore... I'll suggest it to others if we hit this again
It's very well supported. In fact, most features have been showing up in BDB first and then getting implemented in FSFS. It's true that it became the default in 1.2.0, but that was done from a user perspective: it's much easier to set up an FSFS repository for multiple access methods versus a BDB one. Both are very well supported, and neither of them will be leaving in the near future.
> Yes. I actually did that as part of the restore process. When I commited
> it it went though fine.
> It seems to me that this particular user has something 'special' about
> either her setup, configuration, or methods that makes her more likely to
> have an issue. I'm trying to get her to reproduce it in an 'unused'
> repository. The only thing that leaps to mind is her network issues.
It's worth a shot. I've tried everything I can think of to trigger it, but I've never tried disrupting the network traffic. Perhaps it's the key we've been missing in the reproduction recipe.
> Until I can find something the folks on this project are nervous about
> letting her commit anything...
Switch to BDB. If you really don't want to do that, then keep the script posted here handy:
It will recover the revision with no loss of data.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu Jun 1 08:59:36 2006