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 ...
Setup:
* 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)
Stress:
* 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?
...Landon
Received on 2008-03-20 01:54:12 CET