On Thu, Apr 17, 2003 at 10:24:46PM -0500, cmpilato@collab.net wrote:
> Greg Stein <gstein@lyra.org> writes:
> > On Thu, Apr 17, 2003 at 04:15:55PM -0500, kfogel@tigris.org wrote:
> > >...
> > > +++ trunk/subversion/libsvn_client/delete.c Thu Apr 17 16:15:53 2003
> > > @@ -48,9 +48,20 @@
> > >
> > > SVN_ERR (svn_io_check_path (path, &kind, pool));
> > > if (kind == svn_node_dir)
> > > - SVN_ERR (svn_wc_adm_retrieve (&dir_access, adm_access, path, pool));
> > > + {
> > > + svn_error_t *err = svn_wc_adm_retrieve (&dir_access, adm_access, path,
> > > + pool);
> > > + if (err)
> > > + {
> > > + svn_error_clear (err);
> > > + SVN_ERR (svn_wc_adm_open (&dir_access, adm_access,
> > > + path, TRUE, TRUE, pool));
> > > + }
> >
> > The _open will lock the whole tree. If you simply retrieve, do you get the
> > whole tree?
> >
> > If the retrieve works (if you don't need the whole tree), then the _open
> > should not lock the whole tree, right?
>
> There's no such thing as a non-recursive delete, and when a delete
> occurs, the entire tree beneath it is scheduled for deletion, which
> requires write lock for all entries files in that tree. So our
> thinking here was that we *do* want to lock the whole to-be-deleted
> tree -- just not the whole *parent* of that tree.
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.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 18 08:57:30 2003