Philip Martin wrote: > Julian Foad <julianf...@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
