[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Dustin Sallings
Subject: Re: [Gnu-arch-users] Working out a branching scheme [was: tag --seal --fix]
Date: Fri, 2 Apr 2004 09:54:15 -0800

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

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]