Philip Martin wrote:
> 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.
Ack. Okay.
> I have made svn_fs_lock_target_t opaque in the public API which should
> make it easier to add new fields in future.
OK.
Thanks.
- Julian
Received on 2014-04-07 19:48:20 CEST