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

[PATCH] Make "update" check a dir for local mods before deleting it.

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Thu, 09 Oct 2008 16:59:08 +0100

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.

- 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 17:54:31 CEST

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.