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!
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.
Received on 2015-09-25 12:40:18 CEST