Philip Martin wrote:
> Bulk copying locks is a similar issue to bulk copying revprops. [...]
> We should have a better method.
I fully agree.
> At a minimum we need a new FS API that
> allows the lock's creation date to be specified.
Yes, that's one thing that's missing.
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. When bulk-copying, should we take the 'reported at' revision for
each lock, and pass that as the 'current_rev' when locking in the
target repo? If that results in a 'revision is greater than HEAD'
error, that means the source repo received one or more new commits
while we were reading its locks, and so we have to back off and
replicate those new commits before we can validly replicate the lock.
Or if the locking attempt results in an 'out of date' error, that
indicates to us that the target repo has received one or more commits
that have actually changed or deleted a path that we tried to lock.
The current get_locks() APIs are asynchronous with respect to commits,
and don't tell us which revision they are reporting against.
svn_fs_fs__get_locks() doesn't even hold a write lock while it walks
the locks, so I suppose each reported lock may correspond to a
different revision. As far as I can imagine, it should be possible to
make it report the applicable rev of each lock. (The get_locks() APIs
could use the same struct svn_fs_lock_target_t { const char *token;
svn_revnum_t current_rev; } which we use as input to *_lock_many().)
> We don't have dump/load support for locks but we probably don't need it.
> 'svnadmin lslocks' is effectively a dump for locks.
I think as a matter of principle we *should* have a serialization
format for locks. 'svnadmin lslocks' is close, but not safe as at
least the 'owner' and 'comment' fields may contain arbitrary data and
are printed verbatim.
It makes sense for me that we should develop a locks serialization
format, either to be appended to a dump stream or stand-alone, that is
dumped and loaded by either new subcommands or new options in
'svnadmin'.
(When you said we probably don't need dump/load support for locks, I
assume you meant we don't necessarily need to extend the existing dump
format and make 'dump' and 'load' commands support it, if we provide
an alternative way of doing it. I can agree we don't necessarily need
that, but I reserve judgement on which would be better.)
- Julian
Received on 2015-09-24 16:29:32 CEST