Re: [Gnu-arch-users] Archive cycling

[Tom Lord]

    > From: Stefan Monnier <address@hidden>

    > After reading the tutorial and this list, I still don't understand the 
need
    > for archive cycling.  I've used CVS for several years on a an even older 
CVS
    > repository (it actually predates CVS and started as RCS) and have never 
felt
    > the need/desire for archive cycling or anything alike (except maybe for 
the
    > ChangeLog files that are now at revision 5000 or so).

    > So could someone explain to me why it is needed?  Is it specific to tla?

Not _terribly_ specific.  But not unrelated.

Archives (tla or not) are the common-case "default unit of
mirroring".  Arch, of course, encourages mirroring more than other
systems.  Cycling avoids having the default unit of mirroring grow to
large.

Archives (tla or not) are _a_ common-case "default unit of browsing".
In CVS, for example, I might want to look at a list of all the tags
available.   In arch, I might want to look at rbrowse or abrowse
output.  Cycling keeps that browsing focused on what's recent.

Archives (tla or not) are a common-case "default unit of backup
policies".   [yadda yadda yadda]

[etc.]


    > Also, while I understand that tla makes cycling reasonably easy (at least
    > enormously easier than CVS), it still seems annoying, since you have to
    > tell the world that the location of the head has now changed.

Yup.   Hasn't been much of a problem for me yet.   I've cycled a few times.


    > Also when cycling happens, you end up with a temporarily almost empty
    > archive, and since archive crossings are visible to the user (though 
fairly
    > painless), it is somewhat inconvenient since archive crossings will be
    > temporarily a bit more frequent (if people want to see what was changed 
last
    > month, for example).

Sure, and that's one reason why milestone as opposed to calendar-based
cycling might be desirable for some users. 


    > All in all, it seems it would be preferable if we could move "the tail"
    > of an archive: i.e. keep the same archive as the head, but move old 
patches
    > to some other place (like offline/backup/slow/remote server).  It could be
    > done transparently to the people working on the head.

I think that, by the time you get the details down, you'll find that
that's a hairy mess.

However, you can do something just about as good pretty
straightforwardly -- by creating new revisions in the new repository
that simply repeat the last N revisions from the old repository.   For
example, let's suppose that I'm cycling address@hidden to --2005.
In the new archive I could create:


        tla--devo-2004--1.4

in which base-0...patch-N emulate the last N+1 patch from the --2004
archive, and then add:

        tla--devo--1.4

whose base-0 is a tag of tla--devo-2004--1.4--patch-N


-t