You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Julian Foad <ju...@btopenworld.com> on 2008/10/12 16:33:55 UTC
Meaning of --depth=immediates when deleting a tree [was: [PATCH]
Make "update" check a dir for local mods before deleting it.]
Karl Fogel wrote:
> Julian Foad <ju...@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".
> > (1) Is this the right semantics of "svn update --depth=immediates", to
> > go and delete a directory tree that extends to depths greater than
> > "immediates"? Or, by analogy with how it would add the tree "A/..." (it
> > would only add the first level), should it only delete an empty
> > directory and refuse to delete anything deeper?
>
> It would make sense for adding to only add the tree to the specified
> depth (i.e., only add the first level). But I'm not sure that's any
> guide to what delete should do...
>
> > $ svn update --depth=immediates # wants to add A/...
> > A A/
> > # and doesn't add anything deeper.
> >
> > So...
> >
> > $ svn update --depth=immediates # wants to delete A/...
> > D A/
> > # if A/ was empty
> >
> > and
> >
> > $ svn update --depth=immediates # wants to delete A/...
> > Error! or Skipped! or something.
> > # if A/ was not empty
>
> Hmrmrmrmrm. I guess that makes the most sense.
Thanks. I'm not currently planning to touch this, but I may do if it
becomes more of a problem.
> Another possibility
> would be to "unversion" A (as in, its .svn directory would go away),
> while leaving subdirectories below it versioned. Would that be nicer
> for users than just erroring, though?
That doesn't sound nice to me.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Meaning of --depth=immediates when deleting a tree [was: [PATCH]
Make "update" check a dir for local mods before deleting it.]
Posted by "C. Michael Pilato" <cm...@collab.net>.
Julian Foad wrote:
>> 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.
So, it's been a long while since I even typed "adm_access" in our source
files, but I thought for sure that you can sort of "append" new write locks
to a given existing collection of locks held in an adm_access baton. So,
for example, if you need to delete /some/sub/dir and you already have locked
as deeply as /some/sub/dir, you just add to the lock set the children of
/some/sub/dir. If you locked more deeply, you add to the lock set just the
stuff that needs to be locked but wasn't. (And I'd suggest that there
probably could stand to be new svn_wc_adm_* function to do this sort of
magic if such doesn't exist already -- there's no good reason for a given
process to be tripping over its *own* write locks, is there?)
Granted, this is all quite a bit more complicated than the more naive
approach your change reverted us to.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Meaning of --depth=immediates when deleting a tree [was:
[PATCH] Make "update" check a dir for local mods before deleting it.]
Posted by Julian Foad <ju...@btopenworld.com>.
On Tue, 2008-10-14 at 23:15 +0200, C. Michael Pilato wrote:
> Julian Foad wrote:
> > Karl Fogel wrote:
> >> Julian Foad <ju...@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@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Meaning of --depth=immediates when deleting a tree [was: [PATCH]
Make "update" check a dir for local mods before deleting it.]
Posted by "C. Michael Pilato" <cm...@collab.net>.
Julian Foad wrote:
> Karl Fogel wrote:
>> Julian Foad <ju...@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"?
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?)
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand