|
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 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
[Prev in Thread] | Current Thread | [Next in Thread] |