[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: Jason McCarty
Subject: Re: [Gnu-arch-users] [BUG] FEATURE PLANS: "perfect" summary deltas
Date: Sat, 29 May 2004 21:51:39 -0400
User-agent: Mutt/1.5.4i

Tom Lord wrote:
> Here's a plan for self-managing summary-deltas and cached revisions
> with no changes to archive format (beyond adding "system branches")
> and with simplifications to the revision builder.

> [...]

> In other words, the summary version is divided up into phases,
> separated by cached revisions:
>   (revisions explicitly named are cachereved):
>   base-0  ......  patch-K ..... patch-N .... versionfix-X ....
>       `----V----' `------v-----'`------V----'
>         phase 0        phase 1      phase 2      ....
> to build-by-patching, given an existing pristine tree, _within_ any
> phase takes either 2 or 4 changeset applications.  To
> build-by-patching _across_ phases can be accomplished by fetching the
> cacherev at the beginning of the TO phase and building on that,
> instead (at most two changeset applications).

[side note: I'm really impressed with how you're using arch's basic
capabilities to build advanced functionality, in all these recent
feature proposals. Very elegant!]

How well will the summary-generating algorithm handle continuations? If
the tagged revision is similar to the other revisions in the summarized
version, it should work fine. But if it's significantly different, it
would likely start a new phase, and make a cachedrev. It should
probably(?) let the buildrev algorithm follow the continuation instead
of making a cachedrev (unless the tag's to another archive, of course).

Have you considered utilizing the simple changesets of the summarized
branch when building, to jump over the phase and power-of-two
boundaries? You probably get a bit into heuristics at that point, but
suppose a branch with no cachedrevs between base-0 and patch-130. Then
if going from, say, 129 to 126, it's probably considerably faster to
just do 129->128->127->126 than 129->127->0->63->126 (where "->"
represents a changeset). In this case, simply backbuilding downloads
fewer bytes and applies fewer changesets, but a combination of the two
methods might also work well.

Jason McCarty <address@hidden>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]