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. 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*
