[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] [BUG] FEATURE PLANS: "perfect" summary deltas
From: |
Tom Lord |
Subject: |
Re: [Gnu-arch-users] [BUG] FEATURE PLANS: "perfect" summary deltas |
Date: |
Sun, 11 Jul 2004 14:18:35 -0700 (PDT) |
> 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
Re: [Gnu-arch-users] [BUG] FEATURE PLANS: "perfect" summary deltas, Aaron Bentley, 2004/07/10