On Jan 23, 2005, at 7:55 AM, Earl A. Killian wrote:
>
>> This is not expected behavior, no. 44010 files should not cause a 40
>> minute propfind.
> Actually it may have been a 40m REPORT, not PROPFIND, as in the
> 2nd log message. I'm not sure. Would a large number of files
> (7588) in a single directory cause a problem?
This sounds like a well-known scalability bug with svn's http://
access... and it's very rare. I don't even know if it still exists,
but it might.
The recipe goes like this:
- make a propchange to every file in the tree.
- commit. now every file has a different revnum than its parent dir.
- run 'svn up' over http:// :
- the client sends a *huge* report to the server, listing EVERY
file in the tree, because they all have different revnums than
their parent dirs.
- the server, in turn, builds a transaction by linking every
file
into a temporary tree.
- the server compares the temporary tree with HEAD, and
sends a response describing any changes.
The problem is that it takes *SO* long for the server to link
thousaunds of files into the temporary transaction tree, that the
client (neon) usually times out waiting for a response.
I don't know if this problem still exists, now that ghudson has
rewritten the update code in svn 1.1. It no longer builds a temporary
tree, but instead spools the client's report to a tmpfile. And the
comparison code then reads the tmpfile streamily, comparing it to HEAD.
So in *theory*, this problem should be gone; it shouldn't take much
time at all to spool the client's report to a tmpfile. In practice,
maybe something else in happening?
Is the server a 1.0 server, by any chance? If so, that might explain
it.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Jan 23 21:21:48 2005