tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Milstein <dan...@shore.net>
Subject Re: [VOTES] Tomcat 4.0-Beta-1 and New CVS Repositories
Date Thu, 04 Jan 2001 00:17:08 GMT
> 
> 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.

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.

Just I thought I should point this out...

-Dan

> 
> * 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

Mime
View raw message