Re: [Gnu-arch-users] Re: [BUG] FEATURE PLANS: "perfect" summary deltas

[Aaron Bentley]

Andrew Suffield wrote:
> On Sat, Jun 19, 2004 at 11:48:47AM -0400, Aaron Bentley wrote:
>
> > Well, this is an evolution of the ideas we discussed a while back about 
> > smart servers.  The DELTA command proposed back then would provide one 
> > or more changesets which could be applied to produce the revision.
> >
> > The problem is, that assumes the server knows the best way for a 
> > particular client to produce a revision.  I think the right way is to 
> > break it up into a LIST-DELTAS command, that lists deltas that the 
> > server is willing provide.  (This may need to contain a token, so a 
> > smart server doesn't wind up overpromising and underdelivering.)  Then, 
> > the DELTA command can be used to retrieve the individual changesets.
> >
> > You can see how easy that would be to implement with a directory of deltas.
>
>
> In general that's not very useful, because the server should really be
> building deltas and caching based on demand. I think you need a more
> sophisticated discovery mechanism for that, possibly in more than one
> request-response pair.

Okay, I underspecified.  I meant that LIST-DELTAS would have two 
arguments: FROM and TO.  A bushy-tailed smart server would offer reply 
that it would provide delta-FROM-TO.  An overloaded one might return a 
series of deltas that were related to TO.  A dumb server would just 
return a directory listing of the delta dircectory for the TO version.

To go all the way, you might specify that the FROM field should be every 
revision of every version in the library.  The smart server could then 
determine which delta would serve the greatest number.

For a smart server that only generates the deltas sometimes, the caching 
should be fairly simple: for those deltas that it generates, retain the 
most popular in cache, and dump the unpopular.

Aaron