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

Re: Nasty double-replace copy-on-update bug

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2007-10-21 00:02:02 CEST

"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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.