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

Corruption when using --threads

From: Landon Bradshaw <landon.bradshaw_at_justleapin.com>
Date: Wed, 19 Mar 2008 16:53:54 -0800

We've been having a problem with our repository and finally had the time to
do some more testing ... the results are that we needed to drop "--threads"
from our svnserve invocation and just let it run via fork()

Environment: CentOS5
Revision: 1.4.2 (CentOS5) and 1.4.4 (Ubuntu)
DB-type: fsfs

Following these steps I could get a corruption within 10 revisions ...

* create the repo
* create 2 subdirectories
* commit a set of text files into Dir1 (20 files all less than 2KB)
* commit a set of large binary files into Dir2 (6 files of 2.5MB to 16MB)

* By randomly choosing a text file to change I created a new revision for
Dir1 containing 4 to 9 changed files
* By randomly swapping the filename of 2 files in Dir2 I created a large
changeset for Dir2
* Serial commits of Dir2 were continuously occurring while I was randomly
choosing a sleep time between serial commits of Dir1 (<16 seconds)

I would trigger 10 loops of the large swap/commit of Dir2 while triggering
20 loops of revisions from Dir1 and I would reliably get the corruption
before the 10 loops of the binary commits had finished ... "svn:
Decompression of svndiff data failed"

Removing the "--threads" from the svnserve options and I could get through
over 400 commits without an error ... restarting svnserve with that option
and again I would corrupt my repository within 10 commits ...

Is this worthy of posting a bug report? Does someone want my scripts to test
it out themselves?

Received on 2008-03-20 01:54:12 CET

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.