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

Re: Bulk copying locks

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Fri, 25 Sep 2015 11:39:34 +0100

Philip Martin wrote:
> 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. [...]
> Is "the value of HEAD when we read" well defined in all cases? [...]
> 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?

We need to make it well defined.

> 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:
> and I've just discovered that it is even possible to lock directories!
> http://subversion.tigris.org/issues/show_bug.cgi?id=2507#desc28

We seem to have decided that only locking files is what we want.
Should we now enforce that and eliminate the bugs that allow non-file
paths to be locked?

Would that help with fixing the issue of restore/hotcopy/sync of
locks? Yes, I think it would:

We can't currently take any arbitrary set of locks from a src repo and
apply them to a target repo that's at the same head revision, using
even the FS backend APIs, because those APIs error out if a path is a
directory or doesn't exist. And the client-visible behaviour varies
depending on whether those paths are locked, even a path that is
nonexistent or a directory in HEAD. So we can't replicate the state of
the repo using the current APIs.

So I think we do need to fix these bugs.

- Julian
Received on 2015-09-25 12:40:18 CEST

This is an archived mail posted to the Subversion Dev mailing list.