Re: [Gnu-arch-users] archive order?

[Tom Lord]

    > From: Jan Hudec <address@hidden>

    > On Sat, Aug 23, 2003 at 03:03:38PM -0400, Miles Bader wrote:
    > > On Sat, Aug 23, 2003 at 11:32:43PM +1000, Maksim Lin wrote:
    > > > My question is: since most of the time you actually want the latest 
    > > > revision and then sometime (less often) you want to grab some older 
    > > > historical revision, why doesn't the archive actually keep an up to 
date 
    > > > (ie latest revsion) copy of the src and then just apply the 
changesets 
    > > > "backwards" to get older revisions?

    > > Here are some advantages I see in arch's method:

    > >  * An arch archive is (essentially) `immutable,' in that you only ever 
add
    > >    files to it [here by `file' I mean a file used as part of the
    > >    archive/repository implementation, not a source file in a tree], you 
never
    > >    have to change any old files.  This is _extremely_ nice for 
robustness,
    > >    and it keeps things very simple.

    > Which does not include cached revisions (you might sometimes delete
    > them). So saying we should always cache the latest one and remove the
    > previous does not change things that much.

Except for performance.  And it's a really cool area of performance,
too, in the sense that there's gazillions of trade-offs you can make
about who does the work of computing what cached revisions under which
conditions and transmitted across what wires.  Arch gives you quite
easy access to that entire space of trade-offs.  (Incidentally,
"always cache the latest" is likely to _not_ be the best policy.)

    > > Arch does offer some useful tools to keep the annoyance of applying many
    > > changesets in check when you get many many revisions, for instance you 
can
    > > cache whole-tree snapshots of particular revisions in the archive.

    > And there is no reason, why arch shouldn't be able to patch in both
    > directions.

That's quite true and the low-level ground-work is already all done.
There's a little routine called `arch_build_revision' that currently
uses a pretty simplistic heuristic  -- for example, it doesn't even
think about reverse patching, even though the lower-level routines it
uses can support that.   So go nuts -- have fun -- it can probably
absorb as much fanciness as you want to throw at it.


    > In other words, I like the way arch does things. But it could do a bit
    > better, if it was able to create revisions by *both* patching forward
    > and backward.

Planned for and primed.  Patches welcome.

-t