On Sun, 24 Nov 2002, Justin Erenkrantz wrote: > --On Monday, November 25, 2002 12:21 AM -0600 "William A. Rowe, Jr." > <[EMAIL PROTECTED]> wrote: > > > OUTCH! The point to the 2.x history is that we DON'T lose the > > history! I'm guessing I was one of only 5 committers with an rsync > > of 1.2 when the chunk security hole bit us. History is very, very > > precious in a project this large. > > Um, the history is still available via CVS - just at a different > repos. I know that I did a checkout of apache-1.2 and also went to > ViewCVS to track down the chunking commit. The history is still > there - it's just disjoint. Our group precedent here is clearly to > create a new repository rather than using CVS branches. (And, even > now, I still think it's the right decision.)
When the 1.2 vs. 1.3 decision to go away from branches was made, there were a number of bugs in CVS relating to branches that made them just not work right. Those bugs are gone. When the 2.0 repository was created, it was because we knew it would be a complete restructuring of nearly everything. It is far easier to apply changes to code that is the same in both the head and backport to the branch when they are in the same repository. It is then just a matter of a single cvs update command, resolving conflicts, and committing. It is far easier to figure out what has changed between the branch and the head, etc. when it is a branch. If you are looking at 2.1 being as different from 2.0 as 1.3 and 2.0 are, then perhaps a branch isn't the best idea. But if you are looking at having that many differences before 2.0 has even had a chance to stablize, I think you are asking for trouble and how to manage the CVS repository would be the least of the worries... The history is accessible if they are in different repositories, but many operations that are automated via cvs become manual. > > Only if we have many branches; we propose very few. > > I think this is where you and I diverge. I'm taking a very long > perspective in that over time, we would have many branches. For 2.1, > it might not be bad to have them coexist. But, in two years, we'll > probably be at 2.8/3.0 (if not beyond). That's a stable release > every six months which is about our plan, IIRC. I don't plan for our > CVS repositories to last that long. -- justin Having a lot of old branches in a file doesn't really slow down most typical operations (ie. checkout and update) much. What slows things down is having an active branch that is a long way off the HEAD, since it means backpatching from the HEAD to the branchpoint, then forward patching along the branch to get the current version on the branch. It doesn't matter if you have to backpatch 100 revisions then forward patch 10 to go from 2.8 to 2.1 since by that time all we will really care about is 2.7 and 2.8, and 2.7 will still be close enough to the head. Again, it isn't branches that are the problem. It is only active branches and both how many revisions there are on the branch and how far back the branchpoint is from the head.
