Okay.. I finally got the time to look at this again, and here's what
I've got.
Running Joe Orton's subversion-1.0.6 and mod_dav_svn-1.0.6 RPMs on
RedHat Edge Server 3.x (fully updated). The repository in question is
accessed via https using Apache (RedHat's httpd-2.0.46-38.ent). The
https certificate is self-signed (probably irrelevant, but what the
hay). I've changed the default LANG environment variable from
en_US.UTF-8 to just en_US, and have removed the "AddDefaultCharset
UTF-8" which was set by default in the httpd.conf ... I did this to
remove problems we were having with ISO-8859-1 encoded files which our
web developer's tools output.
The web site in question is approximately 1.4GB of data spread over
~17000 files. It's a mixture of HTML, a small number of images
(decoration and buttons, nothing big), Word docs, PDFs and raw text.
The largest file is 18M, and the smallest is 0 bytes.
I've tried doing my initial import using two basic methods. Both
methods fail consistently, but exactly how they fail seems to vary.
First:
svnadmin create
svn import
This method fails in one of two ways:
1) svn locks up. An strace I ran on one iteration showed it was
waiting for a write() call to complete. Apache logs a PUT and
PROPPATCH for the second-to-last file displayed by the svn client. In
this state, svn doesn't appear to respond to any keyboard input, and so
far after 20 minutes it hasn't timed out and died on its own. strace
shows it attempting to handle a ^C, but the sighandler doesn't cause it
to exit. So far I've only been able to get svn to exit by sending it a
sig kill.
2) svn dies with an error like the following:
svn: PUT of
/web-www/!svn/wrk/9384d977-87e3-0310-9c18-e8a479a54b6e/www/fr/webcast/
2002/2002.05.28/fcir020528-avs/msh-jm.htm: Could not read status line:
Connection reset by peer (https://svn.cira.ca)
Regardless of which way it dies, this method leaves a large number of
log.NNNN files in the db directory (anywhere from dozens to thousands,
depending on where in the import it died), and causes the repository to
be unusable. Subsequent attempts to access the repository for any type
of transaction result in a timeout after several minutes.. it must be
deleted and re-created with svnadmin.
Second:
svn create
svn checkout
cp <orig_source> <workdir>
svn add *
svn commit
The commit makes it past all the "Adding.." lines and into Transmitting
file data. This runs for some period of time, then appears to hang for
a while (one strace showed it waiting on a select() call), and
eventually dies with an error like the following:
svn: Commit failed (details follow):
svn: At least one property change failed; repository is unchanged
The last entry logged by Apache in this case is a successful PUT.
I've also received a timeout message here.. though my tests today
haven't produced one so I haven't got a capture of the exact text.
This also appears to leave the database in an unusable state.
Sometimes this leaves only a single log.NNN file, sometimes a couple
dozen.
Of note in all this is that I can regularly import this web site using
a file:// URL... however, putting the resulting repository behind
Apache and trying to do a checkout results in a similar set of
failures.
When the db gets locked up, I've tried running svnadmin recover on it,
and that locks up on an fcntl64() call on locks/db.lock
Because this works fine using only svn with a file:// URL, and because
this web server allows me to read and write many large files using DAV,
I'm inclined to think the problem is in mod_dav_svn somewhere.
I'm at a bit of an impasse now. I can't think of anything else to try
or test. Is there any other information I can provide, or specific
troubleshooting tasks I can perform to help one of the developers track
this down?
Thanks (especially for reading all the way to here)..
Matt
Matt Pounsett CIRA - Canadian Internet Registration
Authority
Technical Support Programmer 350 Sparks Street,
Suite 1110
matt.pounsett@cira.ca Ottawa, Ontario,
Canada
613.237.5335 ext. 231
http://www.cira.ca
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Sep 8 01:22:12 2004