Branko Čibej <brane_at_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*
Received on 2013-12-17 16:15:45 CET