Philip Martin wrote: > Another problem with Ev2. Consider a cheap copy: > > svn cp ^/trunk ^/branches/foo > > With Ev1 this commit sends only a small amount of data across the wire. > This is true even as the number of branches gets large. In the past > there was a backend "big directory" storage problem, but that was > solved > by enabling directory deltafication. > > With Ev2 the "big directory" problem now applies to the network > transfer. Adding a child to branches requires an alter_directory call > with the new list of children, so the old list of children has to be > sent from the server to the client and then the client has to send it > back with the new child added. Very little other data has to be > transferred. For big directories transferring the list of children will > become the bottleneck. > > I think alter_directory should be changed to some sort of delta API: one > list of added children and one list of deleted children. [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.] I guess we should > consider doing the same for the list of properties; perhaps with lists > for added properties, modified properties and deleted properties.
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? - Julian
