Branko Čibej <br...@wandisco.com> writes: > On 17.12.2013 13:48, Philip Martin wrote: >> On the repository side creating or removing a lock involves writing an >> index file for each parent directory in addition to handling the lock >> file itself. To lock N separate files in a directory '/A/B/C' involves >> writing N times the index files for '/', '/A', '/A/B' and '/A/B/C' as >> well as handling the N lock files. To lock N files at depth D we do >> O(N*D) writes but only modify O(N+D) distinct files; it doesn't scale >> very well. > > I don't understand what the index file is for ... could this be > something we could just stop writing? And what about backwards compat?
Operations like delete need to know if there are any locks in a given tree. The index files are necessary to provide a quick answer to questions like: "are there any locks in the tree '/A/B'. Without the index files we would need to examine every path in the tree or every lock in the repository. >> We already pass multiple paths into svn_ra_lock so we could address part >> of the network problem by rewriting some serf code to make it pipeline >> the LOCK requests. That would have the advantage of working with older >> servers but to solve all the problems we need to make HTTP more like the >> svn protocol: send a single request (perhaps POST instead of LOCK?) for >> the repository root and pass all the paths in the body of the request. > > I can't see us using POST instead of LOCK. AFAIU that's in conflict with > the DAV spec; we already know that we could have writen a much more > efficient custom HTTP protocol, and decided against it for good reasons. > Pipelining LOCK requests sounds like the way to go; people can upgrade > their servers if they really want this. Pipelining doesn't allow us to solve the N*M write problem in the repository. We could do it for svn: which already sends a "lock-many" request but not for HTTP. Perhaps that problem isn't important? -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
