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

Re: svn commit: rev 5663 - in trunk/subversion: include libsvn_client libsvn_subr libsvn_wc

From: Karl Fogel <kfogel_at_newton.ch.collab.net>
Date: 2003-04-18 17:33:13 CEST

Greg Stein <gstein@lyra.org> writes:
> I understood that part. But the code above is for locking the
> tree-to-be-deleted. Not the parent. The parent is locked elsewhere, and is
> done as a depth-0 lock.
> As I read the code above, you might retrieve the access baton for the
> top-level-dir of the tree, but it seems possible that the children of that
> tree would not be locked. Sure, the top-level is not locked, *then* you lock
> the whole tree. But it is that _retrieve() that I'm concerned about.

The problem we're working around is:

If the parent access baton *does* have an associated baton for target,
then we must use it (i.e., retrieve it), because we're not going to be
able to get a tree-locked access baton for target any other way. If
we tried, we'd just get an error that the directory is already locked.

Since there's no function for converting an existing Depth-1 access
baton into a Depth-Infinity access baton, we just have to hope that
the baton we get back for target is indeed tree-locked. (If it's not,
there will be an error at the appropriate moment anyway.)

The retrieval won't return a baton right now:

   calls svn_wc_adm_open(&adm_access, parent, NO-TREE-LOCK)
   then calls svn_client__delete(target, adm_access)

     calls svn_client__can_delete(target, adm_access)

       Has the logic described above, where it first tries
       to retrieve the an access baton for target (but fails
       because target's parent was not tree locked), then
       tries to make its own tree-locked baton for target (in
       which it succeeds, and adds that to adm_access's set).

So given the current callers, we always descend into the _open case.
But if a caller *did* hand down a tree-locked parent baton, that would
be fine too. If a caller handed a parent baton with an associated,
but non-tree-locked, target baton, then that would cause an error.
I'm not sure how that could happen, though, without some seriously
unusual stuff going on among the callers.

I'm not saying any of this is pretty, mind you :-). It might be a
Good Thing to write a depth-conversion function; I think such a thing
would be safe. But it's not necessary for this change, afaict.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 18 18:18:08 2003

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.