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

[Aaron Bentley]

Tom Lord wrote:

> I had planned to store a map of available deltas in the patch log of
> the delta-summary branch.

I'm not sure which patchlog you mean here.  The patchlog of the target 
revision can become obsolete when the user deletes revisions.  The 
patchlog of the latest revision might work, but that requires empty 
commits, which I believe are forbidden in your scheme.  (and an 
additional directory listing would be required to determine the latest 
revision.)

> 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.

Well, your policy for generating deltas can be applied to my idea for 
storing deltas.  But as I noted before, your policy generates deltas 
that are entirely redundant with revisions (those with revision ordinals 
of 1) as well as summaries whose benefits are probably outweighed by 
their drawbacks (those with revision ordinals of 2).  So using my 
approach to storage, we could summarize with a revision-ordinal 
threshold of, say, 8, and skip any summaries with revision ordinals 
lower than that.

>     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.

From what I understand, that's what submission branches are.  Am I 
wrong about that?

Another use is to allow people to upgrade from foo--bar--2.4 to 
foo--bar--3.0 in a single step, or similarly across archives.

>   Adding
>        arbitrary deltas complicates the recursion in the builder.

Actually, there's no explicit recursion in the current backbuilder, just 
loops.  But recursion will probably make a comeback when the backbuilder 
goes bidirectional.

>        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?"

The answer to either one is "whatever is the shortest path".  Any path 
that's longer than the current-shortest path can be terminated as soon 
as we know this, and we can eliminate most paths based on the namespace 
alone.

>        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."

I don't think it's possible to get good performance out of the builder 
without some fussy settings.

For example, the current library revision builder will always ignore 
cacherevs if it has previous library revision.  build_revision will 
always use cacherevs if it encounters them.  The backbuilder will ignore 
cacherevs if there's a library revision within 50 revisions.  All of 
these are suboptimal under some conditions.  For a dialup user, 
patch-application time is insignificant compared to download time, so 
that 50 should probably be much higher.

At minimum, a builder needs to know the relative retrieval time of a set 
of patches, compared to the cacherev alternative.  This will vary with 
the archive in question (especially since some are local).  It would 
also help to know the changeset application time.

The only escape from fuss is to decide that it's okay if the builder is 
slow.  I think there are many people who, like me, don't want to have to 
mirror archives in advance in order to save time building the revisions 
later.  So the question then becomses: how much fuss is worth it?

>        Your proposal adds to the complexity of those two choice points
>        in the builder.

Actually, since the backbuilder's non-recursive, we can avoid 
considering non-version revisions after the first choice.

>   There's no great way to make that choice.

Well, I think path length is a resonable approach, but estimated 
retrival time would be better.

And I was planning on adding same-archive descendants to the list of 
possible backbuilding sources anyhow.  (If you have 
tla--devo--1.3--base-0 and you're getting 1.2--patch-115, it's silly if 
it takes more than 1 changeset to do it.)

>        Consequently, your proposal is to create a fussy system.
>        My proposal keeps those choice points in the builder simple,
>        deterministic, and finite.  

We can slap extra restrictions on my system so that it's just as 
deterministic, but if we can eliminate those redundant 1-ordinal deltas, 
it'll still be a win.

Aaron

--
Aaron Bentley
Director of Technology
Panometrics, Inc.