Julian Foad <julianfoad_at_btopenworld.com> writes:
> Imagine the caller is an svn GUI that has an offline mode in which the
> user can queue up lock requests, and the software will send them to
> the server when it's back on line. Does the GUI's back end need to run
> through the queued lock requests and re-group them into batches such
> that all the lock requests in a batch have the same comment?
>
> Or imagine we want to teach 'svnsync' to synchronize locks: it reads
> all the locks in the source repo and writes them to the target
> repo. Do we want to force this software to re-group the locks into
> batches or write them one at a time? Wouldn't it be better if it can
> just say "Here is a bunch of locks; please write them"?
>
> The principle that makes sense to me is, if the semantics of the data
> objects being written is one comment per lock, then the API should
> match that, and not restrict the caller unnecessarily.
Those examples rely on a new RA API that we don't have. Making the FS
API support more than the RA API might future-proof the FS API but it
might also be a dead end that is never used. We don't know exactly how
lock replication will work and whether it will require changes to the
storage backend, but if it does require backend changes then any FS API
we create today may not be sufficient.
Lock usernames are another problem. At present the username is passed
via an svn_fs_access_t and stored in each lock but there is no mechanism
to pass per-lock usernames and no mechanism to modify usernames on
locks. Should we pass per-lock usernames with the rest of the lock
data, or should we introduce per-lock usernames in svn_fs_access_t? The
first is contrary to all other FS APIs, the second is a totally new API
that nobody yet needs. I don't know the answer and since we don't need
this feature yet I prefer not to make a decision at this time.
I have made svn_fs_lock_target_t opaque in the public API which should
make it easier to add new fields in future.
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Received on 2014-04-07 14:56:19 CEST