On Mar 27, 2005, at 9:08 AM, Philip Martin wrote:
> Ben Collins-Sussman <sussman@collab.net> writes:
>
>> 1. How do we find all paths in the lock-token hash which are children
>> of the directory? There's no magical partial-key lookup here, like we
>> have in BDB.
>
> I think the only thing you can do is to iterate over the items and
> check each one. That should be OK for a small number of locks, but
> obviously doesn't scale well. To do better the locks probably need to
> arranged in some sort of tree, either by changing the type of the
> elements stored in the hash or by replacing the hash.
>
> One possibility is to combine the simple iterative search with removal
> of the apr_hash_t from the public ABI, i.e. put the hash into an
> opaque structure and provide accessor functions. That allows a
> relative simple fix to get ra_dav working now, but allows a more
> sophisticated lock storage system to be introduced later.
>
Hmmm, I'm pondering an even more radical idea, though one that might
make DAV experts annoyed.
As I said before, ra_dav is the only network implementation that has to
send tokens with each write request; the other RA layers push them
into the filesystem at the beginning of the commit.
But what if ra_dav did the same? The first thing we do for a DeltaV
commit is create a server-side "activity" (which is an fs transaction).
The whole point of this "activity", as I understand it, is to
compensate for the statelessness of HTTP; every subsequent write
request references the activity as the location of the write.
mod_dav_svn already understands how to make use of per-request tokens,
and this is necessary for interoperability with DAV clients. But
instead of sending all the tokens in the final MERGE request's body,
why not mimic the other RA layers and push *all* the tokens into the
filesystem as part of the initial MKACTIVITY request?
If we did this, then none of the other svn-generated commit requests
would have to send tokens at all. Let the generic DAV clients do that,
we wouldn't need to.
Doesn't this seem a lot more elegant?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Mar 27 19:25:46 2005