On 27/2/03 10:43, "Nathaniel Alfred" <[EMAIL PROTECTED]> 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 find these CVS imports from scratch very disruptive and should not be
> repeated for every major release. Backporting stuff to another CVS
> branch is already hard enough, that you don't want to do it between two CVS
> repositories.
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.
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 1.5.1.1) and you go on from
there (head becomes 1.6, the branched patched version 1.5.1.2), 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...
So, splitting the repository doesn't actually change _that_much_ from user
perspective... You still have to backport stuff somehow, like you would do
for a branch, but at the same time, you can live with two "HEAD" versions
and get a lot faster IO...
Pier
