On Thu, 2008-10-09 at 16:59 +0100, Julian Foad wrote:
> This patch makes "svn update" check for local mods in a directory tree
> that it is about to delete, and raise a tree conflict if there are any.
> This is desired behaviour.
>
> There is just one problem:
>
> # WC contains:
> A/
> A/B/
> A/B/file
>
> $ 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/".
>
>
> (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?
>
> $ 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
>
>
> (2) It looks like if I want to implement my check, I have to get A's
> children and request individual depth-infinity locks on all of them. Any
> better suggestion?
>
> One proposal was to use svn_wc_adm_open3(), but A/ is already
> write-locked, and svn_wc_adm_open3(A/, read-only, depth-infinity) errors
> out if A/ has a write lock.
Actually, I already have a tree walker, so I can just acquire the extra
(read, depth-infinity) lock on each node where and when the attempt to
retrieve an existing lock fails.
Doing that.
- 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-09 18:27:10 CEST