On Tue, 2008-10-14 at 23:15 +0200, C. Michael Pilato wrote:
> Julian Foad wrote:
> > Karl Fogel wrote:
> >> Julian Foad <julianfoad_at_btopenworld.com> writes:
> >>> $ svn update --depth=immediates # tries to delete A/...
> >>> svn: Unable to lock 'A/B'
> >>>
> >>> This errors out because the "update" command puts a write lock only up
> >>> to the depth of "immediates", but then the scan for modifications needs
> >>> at least a read lock to depth infinity inside "A/".
> >
> > I worked around that and committed r33583 to make "update" test the
> > whole deep directory tree, even with "--depth=immediates".
>
> "test"? Did you mean "lock"?
I meant that r33583 makes "svn update" test the whole directory for
local mods before deleting it (or raising a tree conflict if it's
modified).
As part of its operation it does end up with a "read lock" (if that's
the right terminology) on the tree, but it does that by locking (to
depth infinity) each sub-tree that is not already locked, as and when it
encounters such a sub-tree during a recursive walk.
> Would it not have been sufficient to just lock infinitely on an as-needed
> basis (like, when a directory deletion comes across the wire)? (And is that
> trivially do-able?)
I don't think it's possile to request a new recursive lock on a tree
that's already partially write-locked, and at least the root of this
tree is write-locked. If you mean something better than what I'm doing
and that could work in the light of this explanation, please speak up.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-15 00:57:35 CEST