cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <>
Subject Re: [proposal] Pruning up the CVS tree for real
Date Fri, 28 Feb 2003 02:28:52 GMT

On Thursday 27 February 2003 18:58, Pier Fumagalli wrote:
> On 27/2/03 10:43, "Nathaniel Alfred" <> wrote:
> >>> Same as above, I called it cocoon-2.1...
> >
> > So where are the commits towards version 2.2 going once 2.1 is released?
> We create a new repo, called "2.2"...

I kind of like the "new repository" approach, as it is more distinct, and I 
know what to expect. However....

> I agree on the fact that backporting stuff to a branch is quite difficult:
> either you have the branch checked out locally at all times alongside with
> HEAD (and so basically you are already treating the branch as a separate
> repository) and that's what I usually do, or you have to do an update for
> the branch, apply the patch, revert back to head and go on with life.

This also largely depends on what tools you use. If you are in command-line 
mode of the 'original' CVS, yeah it is a real pain, and easy to get things 
wrong, making matters worse.
But the support in NB for instance is pretty extensive, and you can 
practically point-and-click your patches to individual branches in the CVS.
No such support exist for "inter-modules" patches.

> Branching is evil, as it's effectively, a "copy" of the repository within
> the repository itself: effectively, when you "branch" you add two numbers
> to the version at the end (so version 1.5 becomes and you go on
> from there (head becomes 1.6, the branched patched version, so,
> all you literally know is that the original "split" happened at a named
> version (in this example 1.5)...
> But when you branch, and start doing quite substantial changes, the time
> you spend, and the server time you spend in just checking if that directory
> is full or empty, or getting stuff in and out of a ",v" file containing
> branches is just massive...

This is of course a very valid point. The only massively branched large 
project I have been involved in is Netbeans, but their servers seems to cope 
with the load reasonably well. Also, I don't know how much client-side 
caching their client does to improve the perception of speed.


View raw message