"Ben Collins-Sussman" <sussman@red-bean.com> writes:
> And, while glasser and I are still mulling about how to solve the 2
> larger bugs here, I've committed this change in r27297.
> svn_client_checkout() now asks the server to only send fulltexts
> (ignoring copy history), while svn_client_update() asks the server to
> send copyfrom-args on add_file() if it can.
There is another performance issue with flushing the log files early,
each time log files are run the entries file gets rewritten and so for
large directories the O(N^2) file IO can dominate.
Another thing that occurs to me is the locking behaviour of
locate_copyfrom. I believe that if locate_copyfrom is going to
identify files outside the access baton set then it needs to take
write locks, but it should probably not treat a failure to get such a
ock as an error but should fall back on getting the file over RA
instead. Consider a large working copy where the user runs update on
two separate subtrees, a reasonable thing to do if only changes in
those subtrees are of interest. Well suppose a file has been
moved/copied from one subtree to the other, do we want one update to
fail part way through because it cannot get a write lock on the other
locked subtree? I think a user would expect to be able to run
concurrent updates on separate subtrees in a single working copy.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Oct 21 00:02:26 2007