Re: Ev2 alter_directory deltas

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.

-- 
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*