Julian Foad <julianfoad_at_btopenworld.com> writes:
> When bulk-copying from or to a live (writable) repo, there is also the
> issue of knowing which revision the locks belong to. In general, a
> lock is applicable only for a particular revision (or revision range),
> as it becomes inapplicable if the file is deleted, at least. So, when
> reading locks, we probably need to know the value of HEAD when we read
> them.
Is "the value of HEAD when we read" well defined in all cases? Consider
reading all the locks in a subtree. The operation reads the index file
for the directory at the root of the subtree, that gives the MD5 of the
path of every lock in the subtree. It then reads each MD5 file to see
if the lock exists. For each lock there are two read operations: the
index file and the lock file. I suppose we take HEAD when we read the
lock file and not when we read the index file?
Looking at locks on files that no longer exist (issue 2507) I see that
that "svnadmin lslocks" and "svnlook lock" continue to report locks on
paths that do not exist:
$ svnlook tree repo
/
$ svnadmin lslocks repo X
Path: /X
UUID Token: opaquelocktoken:a9fa12c5-d54c-4c94-876b-c261349d4482
Owner: pm
Created: 2015-09-24 23:22:40 +0100 (Thu, 24 Sep 2015)
Expires:
Comment (0 lines):
$ svnlook lock repo X
UUID Token: opaquelocktoken:a9fa12c5-d54c-4c94-876b-c261349d4482
Owner: pm
Created: 2015-09-24 23:22:40 +0100 (Thu, 24 Sep 2015)
Expires:
Comment (0 lines):
and I've just discovered that it is even possible to lock directories!
http://subversion.tigris.org/issues/show_bug.cgi?id=2507#desc28
--
Philip Martin
WANdisco
Received on 2015-09-25 00:35:10 CEST