Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
From: "Carsten Ziegeler" <cziegeler@s-und-n.de>
To: <cocoon-dev@xml.apache.org>
Subject: RE: [PROPOSAL] New CVS Repository Names (Was: Re: [proposal]Pruningup
 the CVS tree for real)
Date: Thu, 27 Feb 2003 13:30:28 +0100
Message-ID: <LKENJPKDAIKAPKHEOCMMIEEMCNAA.cziegeler@s-und-n.de>
MIME-Version: 1.0
In-Reply-To: <BA83ADFB.145FF%pier@betaversion.org>
Importance: Normal
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset="us-ascii"

Pier Fumagalli wrote:
> > So, what will happen, if we release 2.0.5 resp. 2.1?
> >
> > Will we create a new repo for 2.0.6 resp. 2.2?
>
> I do not understand what "resp" means, but I will try to explain: versions
> work, if I got it right, by MAJOR.MINOR.PATCHLEVEL, right?
>
Oh, sorry by "resp." I meant respectivly.

> So, we have (now) two MAJOR.MINOR versions: 2.0 and 2.1: those two minor
> versions are two "forks" (branches, the cocoon_2_0_3 branch and
> HEAD branch)
> of the major version 2.
>
Yes.

> When you "branch" then you start working on patchlevels, so, for example,
> 2.0.0, 2.0.1, 2.0.2, 2.0.3 and so on are all in the same "branch" in the
> same "2.0" fork, as, what will happen for 2.1, the different patchlevels
> 2.1.0, 2.1.1, 2.1.2 and so on will live in their own little HEAD
> branch (for
> now, until we start 2.2, and then they will be "branched out" again)...
>
> So, if a "branch" coincides with a MAJOR.MINOR version number,
> and we don't
> have any advantages in keeping those two branches in the same repository
> (are there any that I don't know of?) we can simply have another
> repository
> with a clean copy of our MAJOR.MINOR version, so that we won't
> waste so much
> time everytime we check out, diff, committ or stuff...
>
> Now, PATCHLEVELS: those should be a tag... A tag is a unique
> identifier of a
> given release, but it doesn't "branch" out so that you keep basically
> working on the same MINOR.MAJOR codebase, and at some point in time you
> declare it to be MINOR.MAJOR.PATCHLEVEL...
>
> You don't use a branch for a given patchlevel because you're not
> going to do
> further development in both branches: for example, what is the
> cocoon_2_0_3
> branch? Are we going to have 2.0.3.1, 2.0.3.2 and so on? Why is
> it different
> from the cocoon_20_branch?
>
> So, to sum up:
>
> HEAD:    initial ->  2.0  ->  2.1  ->  2.2  ->  ...
>                       |        |        |
>                       V        V        V
>                     2.0.1    2.1.1    2.2.1
>                       |        |        |
>                       V        V        V
>                     2.0.2    2.1.3    2.2.3
>                       |        |
>                       V        V
>                     2.0.2    2.1.3
>                       |
>                       V
>                     2.0.2
>
> Vertical lines are "branches", the horizontal line is "head",
> each number is
> a "tag", and some of these tags are also "branching"... This is
> what should
> happen in a nice little world...
>
> Splitting branches into repositories, then, doesn't change much from our
> perspective, but will do from the server standpoint, as it is much much
> faster to have small "tag-only" repositories than one big repository with
> branches and years of history... CVS doesn't scale, we need to hack our
> development process around it to make it work...
>
Thanks for your explanation. I just want to repeat it with two simple
statements in order to see that I did this correct:
- One repository for each MAJOR.MINOR combination
- Inside a repository are all patch levels. Each one tagged, but there
  wont be any branching

Hmm, ok I can live with that.

> Now, SVN is another story, it _will_ fix those design bugs that CVS
> introduced and that forced not only us, but everyone, to "hack" around CVS
> to get it working decently...
>
Would something change if we would use SVN now or later-on? Which means,
if we would use SVN right now, would we have only one repository? And if
we use SVN in some months time, would we have to change the number of
repositories again?

Carsten