Re: [Gnu-arch-users] Working out a branching scheme [was: tag --seal --fix]

[Tom Lord]

    > From: Dustin Sallings <address@hidden>

    >   This is getting closer to my point.  The original point was to use 
    > something--version--0 as head-of-line and do all new commits there, and 
    > then tag releases and merge from HOL into those releases.  In this 
    > model (the model I've always used in CVS and perforce), HOL goes on 
    > forever.

    >   On one hand, it seems a lot easier to explain and coordinate, but it 
    > does seem that long lines of development are discouraged.

One thing to consider is just the structure of the arch namespace.

You can do the split-up between branches by varying the archive
component.   Thus, you do have one _huge_ line called:

        */something--version--0

where the `*' matches a list of archive names that you are free to
take care to make sortable.

CVS really _doesn't_ scale infinitely far this way.   Eventually your
,v files (or whatever the heck they are called) grow too large.


    > > Someone mentioned the interesting case of a CVS archive that cscvs
    > > calculates at 11,000 revisions.  Aside from needed to tweak cscvs for
    > > this purpose or build some new scripts around it -- is there any
    > > reason to not want to split that into successive versions?  It's

    >   I wouldn't know how to do something like that.  It was one line of 
    > development in CVS, why wouldn't it be one line in arch?

It is one line -- just a line split over multiple archives (or
multiple versions or branches or however you want to do it.)

It's almost never going to be right to keep unbounded history in one
place, like that.   For example, your backup procedure times and
storage costs are then O(n) instead of a saner O(log n).


    > > unlikely there's be any utility to keeping that many patch log entries
    > > in the tree and, if you're going to prune, you'll want some version
    > > boundaries in there to serve as the unit of pruning.  Sheesh --- can
    > > you imagine tagging the latest revsion in an 11,000 revision version?
    > > The need for "log summaries" aside -- the log message of the tag would
    > > revision would be a better fit for your 80-bytes-per-revision size
    > > estimate.

    >   I guess I don't really understand log pruning.  It sounds like you're 
    > referring to removing history from a tree, but that doesn't exactly 
    > make sense due to archive immutability.  I wouldn't import the tree if 
    > I didn't want the history of the changes.

    >   Is there a description of what log pruning means somewhere?

Don't know if there's a description but we're talking about triming
the {arch} subdir in later revisions of a tree --- not modifying
history.   

What I've taken to doing for now is to generate changelogs for things
I'm pruning and then just removing the corresponding logs.
Space-savings for changelogs aren't all that high -- eventually I'll
probably want to get rid of some of those as well.

For example:  the `tla' tree is derived from a signficantly older
`file-utils' tree.   I've pruned the `file-utils' log.   Thus, I can't
star-merge in changes from a file-utils version I was using in 2001
unless I do some log restoration.   I'm not exactly worried about
that, though.

What's currently missing is a trivial mechanism for restoring parts of
past logs.  Right now I'd have to fuss around for an hour to bring
back some old log.

Later, as I said, I expect to automate pruning and restoration.   So
then, yes, I _will_ be able to star-merge in from way-back-when.   But
it's not a pressing issue and I want to wait until actually confronted
with the problem to work out the details of the best way to do it.

-t