Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Message-ID: <3A53C35B.3A014D0E@eng.sun.com>
Date: Wed, 03 Jan 2001 16:27:07 -0800
From: "Craig R. McClanahan" <Craig.McClanahan@eng.sun.com>
MIME-Version: 1.0
To: tomcat-dev@jakarta.apache.org
Subject: Re: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories
References: <80F5674514B4D311BAFC0040F6A45EEE0BE285@ntserver>
 <3A53C026.273EBAE2@eng.sun.com> <3A53C104.FBA442CB@shore.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Dan Milstein wrote:

> >
> > On the other hand, a separate repository causes no problems that I've
> > experienced, and avoids all of the issues listed above.
>
> I agree that branches under CVS are way, way confusing, and so I'll support a separate repository.  The one disadvantage I do see, however, is that we'll lose the ability for CVS to automatically merge changes from one branch into the other.  For example, if we have a 4.0 and a 4.1 ("Head") branch, then, *in theory*, we could make bugfixes on 4.0, and then ask CVS to automatically merge those fixes into the "main" 4.1 branch.
>
> With separate repositories, we'll have to do those merges by hand.
>

Point well taken.

I'm not at all a fan of automated merges ... CVS gives me enough grief already merging conflicts on individual files :-)

>
> On the other hand, having worked extensively with CVS branches, those merges between branches are very temperamental, so I want to emphasize the "in theory" part.
>

Yep.  It is one of those "sounds wonderful" things, but I cringe every time I run one.

Also, my historical experience has been that the need for branch merging *between* dot releases (4.0 and 4.1 in this scenario) is quite a lot less common than merging code branches *within* a dot release.

But the option to do this automatically is something we give up.

>
> Just I thought I should point this out...
>
> -Dan
>

Craig


>
> >
> > * Branches are mysterious to CVS newbies, and make
> >   the learning process that much harder than it needs to be.
> >   It's also messier for folks (like me) who have to work on
> >   multiple releases at the same time.
> >
> > * Branches tend to be less visible to project newcomers --
> >   for example, anyone who checks out the main branch of
> >   "jakarta-tomcat" today is going to wonder why it is quite
> >   different from the 3.2.1 source distribution that he or she
> >   grabbed off the web site.
> >
> > * Branches make life harder for "automated check out and build"
> >   scripts like the one I use to create nightly distros of several of
> >   the Jakarta packages, and like what Sam Ruby is building at:
> >
> >  http://oss.software.ibm.com/developerworks/opensource/jakarta/proto/index.html
> >
> >   You have to make special provisions in scripts like this to check
> >   out branches other than the main one, which makes them more
> >   fragile and error-prone.
> --
>
> Dan Milstein // danmil@shore.net
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, email: tomcat-dev-help@jakarta.apache.org