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