[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Can't read length line in file (again).

From: Andrew MacKenzie <amackenz_at_edespot.com>
Date: 2006-06-02 18:14:54 CEST

> Would it be possible to see both the rev file and the script you used to
> produce it? If the rev file isn't all that big, you can send it to me
> privately. If it's bigger, if you could post it somewhere, that would be
> great. I can then look at it and tell for certain whether or not it's
> the same bug or something different.

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...

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
n=
ormal
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).

> 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).

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'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.

> I'm glad you were able to produce something!
Me too. Hopefully it's helpful. Let me know if you need anything more.

-- 
// Andrew MacKenzie  |  http://www.edespot.com
// GPG public key: http://www.edespot.com/~amackenz/public.key
// There are a lot of lies going around.... and half of them are true.
//                 -- Winston Churchill

  • application/pgp-signature attachment: stored
Received on Fri Jun 2 18:16:15 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.