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

[Tom Lord]

    > From: Aaron Bentley <address@hidden>
    > 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.

I had planned to store a map of available deltas in the patch log of
the delta-summary branch.   Parsing the log message is no easier or
more difficult than parsing the directory listing.

Thus, the two big differences between my approach and your approach
are:

    1.  For a given TO-REVISION, my approach says which deltas to make
        to that TO-REVISION, yours is free-form, presumably requiring
        an external or by-hand creation of deltas.  Yet my policy is,
        I believe, a pretty good approximation of optimal placement of
        deltas --- so I'm not sure you gain anything by your added
        flexability here.

    2. For a given TO-REVISION, your approach allows summary deltas
       from other versions, mine does not.   

       I get the concept of a builder that would use this but I don't
       see any practical realization of that concept.   Adding
       arbitrary deltas complicates the recursion in the builder.   
       Having to build some revision it finds it doesn't have on-hand, 
       it gathers up all of the available deltas and looks to see which 
       prereqs it might have on hand.  If it has a set of prereqs on
       hand, it picks one and builds based on that.  If it has none,
       it picks from the set of prereqs for "what to recursively
       build".

       So there's two choice points the builder might reach for a
       given revision:  "Which of the prereqs that I have should I
       actually use?"  and if not that choice, then:  "Which of the 
       prereqs I could use should I recursively build?"

       I don't like "fussy" tuning options unless they are absolutely
       necessary.   A "fussy" tuning option is one in which there
       is no setting of the tunable parameters which is actually 
       safe for all usage patterns.   Whatever setting you chose, 
       you're effectively declaring "I'm only going to use this tool
       in modes for which this setting makes sense."

       Your proposal adds to the complexity of those two choice points
       in the builder.   There's no great way to make that choice.
       Consequently, your proposal is to create a fussy system.

       My proposal keeps those choice points in the builder simple,
       deterministic, and finite.  If such and such summary deltas
       exist, use them (following pretty much the existing butt-simple
       build algorithm) -- otherwise, build in the dumb way.  It's
       guaranteed to terminate in <= the number of steps it takes for
       a dumb build.  It's guaranteed to use <= the amount of
       bandwidth.   It's not fussy.

-t