On 10/20/07, Philip Martin <philip@codematters.co.uk> wrote:
> "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.
Philip, can you take a look at my patch in the thread "[PATCH] Fix
issue 2986"? It fixes the loggy problems, though not the
locate_copyfrom things.
--dave
--
David Glasser | glasser_at_davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 25 05:07:04 2007