httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <ma...@znep.com>
Subject Re: 2.1 Fallout; httpd v.s. httpd-2.0
Date Mon, 25 Nov 2002 06:56:19 GMT
On Sun, 24 Nov 2002, Justin Erenkrantz wrote:

> --On Monday, November 25, 2002 12:21 AM -0600 "William A. Rowe, Jr."
> <wrowe@apache.org> 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.



Mime
View raw message