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

[Aaron Bentley]

Tom Lord wrote:

> Somewhat worse than that, I think.  Every summary delta is almost
> certain to be larger than the corresponding revision delta.  In the
> worst case (or depending on how you tune the summary branch) the
> average summary delta size converges and stays at some constant
> fraction of the size of a cacherev.
>
> Yet I think it's a good design.  Those nasty things are inevitable
> properties of _any_ kind of static (dumb-server friendly) summary
> delta solution and you can offset them only by allowing "lacunae"
> (missing summary deltas).

Well, I think a solution involving a "deltas" directory that contained 
all deltas with a TO-REVISION in that version would be faster, more 
flexible, smaller and more straightforward.

It would be faster, because you could use a single directory listing to 
find out which deltas were available instead using a bunch of requests, 
and getting slowed down by latency.

It would be more flexible, because you could produce a delta from any 
revision, even external ones.  For example, I could have a delta (in my 
errors branch) named:
address@hidden

When you (or anyone else with 1.3--patch-26 in their revlib) wanted to 
get my tlasrc--errors--3--patch-10 revision, you could just use that 
delta.  In other words, this generalizes submission branches and summary 
deltas into the same approach.

It saves space, because you don't get redundant deltas. In your delta 
scheme, patch-1, patch-4 and patch-8 are redundant with the summarized 
branch.  And even patch-2, patch-5 and patch-9 are unlikely to reduce 
download time significantly.  But if deltas aren't stored as branches, 
there's no need to have one revision per summarized revision, so those 
deltas wouldn't be needed.

It would be more straightforward, because it wouldn't introduce unwanted 
patchlogs, it wouldn't introduce new kinds of branches that were 
inaccessible.  It also wouldn't break the expectation that "if a 
revision exists, the namespace-previous revision also exists".

Aaron