You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@s-und-n.de> on 2003/02/27 11:51:43 UTC
RE: [PROPOSAL] New CVS Repository Names (Was: Re: [proposal] Pruningup the CVS tree for real)
Thanks Pier!
Pier Fumagalli wrote:
>
>
> - Rename the "xml-cocoon" repository to "cocoon-1"
> (you can see the effect of this as now both repositories are
> accessible
> with the old and new names: they are an alias one of another)
>
Ok.
> - Rename the "xml-cocoon2" repository to "cocoon-2-historic"
> (you can see the effect of this as now both repositories are
> accessible
> with the old and new names: they are an alias one of another)
>
Ok.
> - Create a new repository called "cocoon-2.0" and copy over the
> cocoon-2_0_5
> branch of "xml-cocoon2" (clean checkout, and re-import)
> (this has been created as a part of this proposal, and it
> contains what
> it should. All files are down at version 1.1 in this repository)
>
> - Create a new repository called "cocoon-2.1" and copy over head from the
> main "xml-cocoon2" repository (clean checkout, and re-import)
> (this has been created as a part of this proposal, and it
> contains what
> it should. All files are down at version 1.1 in this repository)
>
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?
Carsten
RE: [PROPOSAL] New CVS Repository Names (Was: Re: [proposal]Pruningup the CVS tree for real)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
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
Re: [PROPOSAL] New CVS Repository Names (Was: Re: [proposal]
Pruningup the CVS tree for real)
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 27/2/03 10:51, "Carsten Ziegeler" <cz...@s-und-n.de> wrote:
> Thanks Pier!
You welcome! :-) Pleased that we're starting to come out of this empasse...
> Pier Fumagalli wrote:
>>
>> [...]
>>
>> - Create a new repository called "cocoon-2.0" and copy over the
>> cocoon-2_0_5
>> branch of "xml-cocoon2" (clean checkout, and re-import)
>> (this has been created as a part of this proposal, and it
>> contains what
>> it should. All files are down at version 1.1 in this repository)
>>
>> - Create a new repository called "cocoon-2.1" and copy over head from the
>> main "xml-cocoon2" repository (clean checkout, and re-import)
>> (this has been created as a part of this proposal, and it
>> contains what
>> it should. All files are down at version 1.1 in this repository)
>>
> 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?
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.
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...
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...
Pier