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

[Dustin Sallings]

On Apr 2, 2004, at 8:17, Tom Lord wrote:

> Third, remember, though, that at 10K patches _in_a_single_version_
> we're really in the realm of a comfortable overestimate of anything
> people should reasonably want.  If created over a long period of time,
> such a long line of development should be split into successive
> versions.  If created over a short period of time -- what the heck is
> going on?  You really expect people to do something reasonable with
> _that_ high a rate of change on a single line?  So, over a
> short-period of time, I think you'd want it split into parallel
> versions.

	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.

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

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

--
Dustin Sallings