[snip]
> I've posted the last 5 revisions (and other data) here:
> http://www.edespot.com/~amackenz/test_revisions/
>
> Oddly enough it isn't the last revision that "svnadmin verify" dies on. It
> seems to fail at 8204, not 8205...
Correct. The problem isn't seen at commit time. It's seen after the fact. It only when you do an operation against that revision, such as an 'svn cat' of the affected file, or the backend decides to use that revision as one of the skip-delta basis, does it show up. Of course, 'svnadmin verify' will find the problem too.
>
> My script was something like this (also at the above URL, it's called
> "go"):
> while true
> do
> for i in 1 2 3 4 5
> do
> echo "*****************************************"
> echo "Using ${i}Mb of data."
> dd if=3D/dev/urandom of=3Dfile.out count=3D${i} bs=3D1M
> svn commit file.out -m "Commiting random binary data"
> echo "Sleeping..."
> sleep 20
> done
> done
>
> I did do some commits using TSVN as well here and there.
>
> I ran the following on my Linux router's "external" interface to
> simulate a
> bad network connection:
>
> tc qdisc add dev eth0 root handle 1: netem delay 100ms 500ms distribution normal
> tc qdisc add dev eth0 parent 1:1 handle 2: netem loss 2%
>
>
> That should vary network latency 100ms +/- up to 500ms, and drop 2% of
> packets. It makes things *very* slow. :-)
>
> To stop it, BTW, run this:
> tc qdisc del dev eth0 root
>
> I should also note that some commits I 'killed' (ctrl+c), and did "svn
> cleanup" to recover, then continue again. I don't recall whether the bad
> revision had this done to it or not, but I believe I had done it recently.
>
> I think this may be key. I had let it run for some time and it just seemed
> 'laggy', but otherwise working around the network issues as it's supposed
> to. It wasn't until I began to get impatient with the lagginess induced
> by the network that I started to stop and restart the script in the middle
> of commits (rather than waiting for the 'sleep' command to stop it).
Okay. Without being aggressive about starting/stopping commits, I was not able to reproduce the problem. I'm going to have to try again with start/stopping the script in the middle of things.
>
> > As for the reason you can't remove the transactions, I'd really have to
> > see the whole repository to comment on that.
>
>
> Hrm. Since I used a copy of a repository folks here are working on I can't
> provide that... But I did have this issue before in the other repositories
> that got corrupted (at least the second time; I didn't check the first
> one).
Understood.
>
> I did, however, copy all the outstanding transactions from
> test\db\transactions to the above URL. They should only involve my test
> file so that's fine. The ones that couldn't be removed are 8184-4 and
> 8184-5.
I didn't see these on the website.
>
> I'll do some more testing this weekend to see whether I can recreate this
> in a fresh repository. I'll try to keep closer track of exactly what I do
> also. That way I can provide you with all of my test material.
Please do. Until we really see this problem happen, it's tough to come up with a good fix for it.
>
> > I'm glad you were able to produce something!
>
>
> Me too. Hopefully it's helpful. Let me know if you need anything
> more.
I'm going to try again sometime with starting/stopping that script. I did take a look at r8204, and it's definitely affected by the same problem. So if we can get this test setup to a point where we can understand how to make the issue show up, we can start tracking down exactly how the problem is created and come up with a proper fix. Thanks for your help! I feel like we're getting closer. If I could just see it happen... :-)
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jun 7 11:56:12 2006