Re: Ev2 alter_directory deltas

Philip Martin wrote:

> Julian Foad <julianfoad_at_btopenworld.com> writes:
>> Philip Martin wrote:
>>> [Conceivably
>>> the RA implementation of the current Ev2 API could deltify the list
>>> sent back by caching the list received but that's horrible and doesn't
>>> solve the problem of getting the list in the first place.]
>>
>> Why is this different from the delta-transmission of file content? 
>> The principle of Ev2 is to describe changes in terms of "the new state
>> is Y" at the API level, and to leave deltification to be arranged
>> between the producer implementation and the consumer implementation. 
>> Why cannot properties be handled this way, and why cannot (or should
>> not) children-lists be handled this way?
>
> For this operation
>
>   svn cp http://host/repo/trunk ^/branches/foo
>
> I don't see how to avoid the having the server transmit the existing
> children-list to the client.  Ev2 has introduced that inefficiency.  I
> can see that with caching we could implement some sort of delta for
> sending the children-list back to the server, but even that looks ugly.
> Does the RA layer cache every children-list received?  Does the client
> provide a callback for the RA layer to cache and retrieve
> children-lists.
>
> A cheap branch operation which transfers a few dozen bytes in Ev1 (plus
> a few thousand bytes for HTTP headers) will have to transfer Megabytes
> with Ev2.

Right, I understand your use case now, and agree.

The root of the problem, as I recall, is the WC DB requirement that, before updating the DB entry for directory "DIR" to revision REV, there must be child entries in the DB corresponding to (at least) all the children of DIR_at_REV in the repository.  I'm not 100% sure about that requirement.  I recall something about how by doing this we could avoid marking the directory itself as incomplete but only mark its new children as incomplete, and this was considered to be a good thing.

From that requirement we extended and derived a requirement for Ev2 that an alter-directory(children=X) must be issued before any calls that change the list of children.  At first sight, that rule seems to fit well with the principle of the Once Rule, if we assume that a typical receiver (WC or repository) will treat a directory node as an object that contains a list of children, and will want to update it in one shot.  However, it may not actually be as good a fit as it seems.  A repository will probably need more information than simply a list of child names: it will want to know the corresponding node ids, and it won't know them until any copies, adds come in.  So we should be careful about assuming this alter-dir is necessarily useful.

There are any number of ways we could change things.  I don't currently have a strong enough handle on the exact reasoning to be able to suggest the best course of action.

- Julian
Received on 2013-08-14 15:52:10 CEST