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

[Tom Lord]

    > From: Aaron Bentley <address@hidden>

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

If a log entry (the latest (or such) in the summary-delta branch)
becomes out-of-date because of deleted revisions, that means just one
extra roundtrip (to discover a revision has been deleted).


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

Yes, clearly.  But your idea for generating deltas implies fairly
significant and uncertain changes to the builder whereas mine implies,
imo, fairly trivial and deterministic ones.

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

I've been thinking a bit about the revisions with ordinal 0 and 1 ---
it's interesting to note that maybe I should think about 2 as well.

I have no problem making those special cases.   I wonder if something
interesting can be done with them.   For example, they could be used
in a variation of my scheme to extend the set of revisions reachable
from a given revision N in 4 or fewer changeset applications (with the
changeset sizes not adding up to a cacherev size).


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

?

I certainly don't want to implement submission branches that way
(using your "delta" directory).  One way to understand the "point" of
a submission branch is that I should be able to "get-patch" the
changeset from it and it should represent a proposed divergence from
some mainline.  A purely "commit --continuation" branch fits the bill
precisely --- all that's needed (at core) is to remove the restriction
that currently prohibits "commit --continuation" revisions.

-t