>
> 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 // [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
