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