So is it safe for an access baton just to ignore the already locked
descendant items for the current tree locking? this would assume that
locks are shared within an access batons, which i'm not yet sure what
the design was. But It shouldn't be hard if it's the case. Otherwise
there should be some other mechanism resolving this?
And could we have the fix in before fixing the api discussed here?
(after the patch got some general cleanups of course)
The commit performance problem is really annoying for running vcp
conversion from cvs to svn.
On Thu, Jul 10, 2003 at 11:51:44PM +0100, Philip Martin wrote:
> I feel that having a requirement to sort the paths first means the
> that the svn_wc_adm_open_descendant API is broken, the user has to
> know the entire history of the access baton, which conflicts with the
> "open if not already open" behaviour of this function. It really
> would be better to get it to do the right thing, possibly by
> refactoring the tree_lock stuff from do_open. I suspect that doing
> this would also get rid of the closing and re-opening of the basedir
> problem.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 11 01:19:01 2003