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

[Jan Hudec]

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.

>  * Arch's method makes commits much faster, and commits are far more common
>    than whole-tree checkouts (which is the main big advantage you get from
>    CVS's method).
> 
>  * In arch, branching is encouraged and made simple (whereas in CVS it's
>    painful at best).  If you have branches, then there really _is_ no
>    distinguished `HEAD' revision in which to `store the expanded sources.'

Each branch has one.

>    Even if you were to let the user arbitrarily specify one, it would
>    probably be more complicated and far less useful than you think -- if
>    there are lots of branches, they'd either all need their own copy of the
>    `expanded' tree, or else would have to revert to using basically the same
>    method arch uses now.

There is no problem _keeping_ the method arch uses now. It'd be in fact
prefered to keep it.

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

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.

Reason is, that probability that you need some revision is inversely
proportional to it's age. So most of the time, backpatching from
pristine tree would be fast and greatly reduce the need for cached
revisions (you would still want to have one now and then in case you
need something old).

-------------------------------------------------------------------------------
                                                 Jan 'Bulb' Hudec 
<address@hidden>