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

[Tom Lord]

    > From: Aaron Bentley <address@hidden>

    > Tom Lord wrote:

    > >     > The archive.h-level stuff needs to be of the form "what are you 
willing 
    > >     > to give me that can get me from here to here."  

    > > It does not.  This has been discussed in the past.   Gah... I wish you
    > > were near enough that we could sit down at a pub table with a sheet of
    > > paper: I'm increasingly getting the impression that there's some
    > > disconnect between us about builder issues that needs to be debugged.

    > > In some cases a server may decide that the delta from X to Y is best
    > > provided as a list of composable deltas, but their composition should
    > > take place behind the archive.h scene.

    > When we trace a path, we get a list of deltas like this:

    > address@hidden/tla--devo--1.1--patch-287
    > address@hidden/tla--devo--1.2--base-0
    > address@hidden/tla--devo--1.2--patch-1
    > ...
    > address@hidden/tla--devo--1.2--patch-115
    > address@hidden/tla--devo--1.3--base-0
    > address@hidden/tla--devo--1.3--patch-1
    > ...
    > address@hidden/tla--devo--1.3--patch-26
    > address@hidden/tla--devo--1.3--patch-27
    > address@hidden/tla--devo--1.3--patch-28

This is not directly responsive to where you're going but I want to
note that building via an ancestry of that length (in time and number
of revisions) is very, very far from the expected case and, moreover,
is a case it makes almost no sense at all to optimize.   Over that
distance, you're better off just getting a whole-text of the desired
revision; build-by-patching is silly and likely to be pessimal (unless
your goal is to fully populate a revision library).


    > The first line is the first FROM revision, and the second line is the 
    > first TO revision.

    > So it's a list of deltas, where each delta is the delta between adjacent 
    > revisions.

    > Of course, right now, we just apply-or reverse-apply revision 
    > changesets.  But I expected that we'd be changing things so that the 
    > list was a true list of deltas later.

    > Now, I suppose it's possible that, having generated all this, we can 
    > throw most of it away, and just do

    > arch_apply_delta(tree, arch, 
    > "address@hidden/tla--devo--1.1--patch-287", 
    > "address@hidden/tla--devo--1.3--patch-28")

    > For pfs archives, we'd have to rescan the archive to generate the same 
    > list.  So that's clearly bogus.

    > So I guess we're left with
    > arch_apply_deltas(tree, arch, delta_list)

    > And then have the smart server do what you want, rather than what you 
    > asked for.

    > Is that what you have in mind?

We were talking about smart servers and their impact on archive.h.

You were suggesting something where code above archive.h asks for a
list of "what deltas can you give me to get from A to B?".

That question is a question to ask of a smart server, but _below_
archive.h.   The archive.h interface we worked out w/cduffy would
let you say "give me delta(A,B)" and give you back a single
changeset.   A server might provide that delta directly, or it might
provide a list of deltas which (underneath archive.h) are composed,
client-side.

The idea here is to liberate servers to minimize their server-side
computation and outgoing bandwidth by letting clients do the assembly
work (changeset composition).

-t