> > 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 checksums
> 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 wrote a script to create ramdom binary data in a file 2-5 meg in size,
> > and commit it. I ran this script over night from my own VPN connection
> > (just commiting the same file over and over again with random changes). It
> > ran flawlessly...
> I've done similar things, with small and large files on a multiprocessor
> machine. In fact, I believe I ran it for about 40 hours straight, and
> got nothing. :-(
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...
> One way to avoid this particular issue is to switch to the BDB backend.
> Given your configuration, there should be little worry of it wedging.
> Just be careful when upgrading as we've seen some issues with BDB and
> their upgrade process. In general, it's not a big concern though.
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
though.
> > Anybody have any ideas on how I can reproduce this? Any test scenarios?
> > If more information is needed I will try to provide it.
> Have you tried dumping the repository to the version the repository was
> at when your user was committing, and trying to commit the file?
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.
Until I can find something the folks on this project are nervous about
letting her commit anything...
--
// Andrew MacKenzie | http://www.edespot.com
// GPG public key: http://www.edespot.com/~amackenz/public.key
// In computing, invariants are ephemeral.
// - Alan Perlis
- application/pgp-signature attachment: stored
Received on Thu Jun 1 03:34:52 2006