Julian Foad <julianfoad_at_btopenworld.com> writes:
> Philip Martin wrote:
>> 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
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
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Received on 2013-08-14 12:40:03 CEST