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:28:28 UTC
RE: What Cocoon is really doing wrong [was: CVS repositorychanges... (and what's left to do)]
Pier Fumagalli wrote:
>
>
> Maybe I should have pointed out that the change is backward
> compatible? Did
> you try doing "cvs co xml-cocoon2"? It still works...
>
> It's not that things can be "reverted", it's that things, for the eyes who
> doesn't want to see the change, does not exist... The repository name,
> LITERALLY is still there, with the old name and the whole
> thing... The only
> thing you see now are also few new "repositories" which are my proposal to
> this list (it's an infrastructure "diff" with a lot of + and no -
> lines) :-)
>
> Sorry if I wasn't clear from the beginning...
>
So, you created new repositores as part of your proposal?
What will happen if I now check-in something only into the old rep?
What will happen if I now check-in something only into the new rep?
I don't see that it helps to create a repository to discuss how it
should be named.
So can we then simply start a proposal on how to name the repositories?
Thanks
Carsten
Re: [PROPOSAL] New CVS Repository Names (Was: Re: [proposal]
Pruning up the CVS tree for real)
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 27/2/03 11:39, "Gianugo Rabellino" <gi...@apache.org> 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)
>
> +1. But what happens from there on? No more branching, I assume, just
> tagging as 2.0.x release happens. Right?
Yessir! :-) That would be just fantastic...
>> - 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)
>
> Here I'm not sure. ATM I'd rather have the latest cocoon version in a
> repository such as plain "cocoon" (think CVS HEAD). In this Cocoon
> lifecycle it represents 2.1. When we release 2.1, we can move this repo
> to cocoon-2.1 and start using it (with tagging, no branching) for 2.1.x
> releases, while "cocoon" would become the 2.2 repo. Isn't it cleaner
> from a logical POV?
That's a good idea... How about if we keep the module symlinked... So,
"cocoon" is the current copy, which is a symlink to whatever is the current
version "cocoon-2.1" now, "cocoon-2.2" "cocoon-3.0" and so on in the
future...
Pier
Re: [PROPOSAL] New CVS Repository Names (Was: Re: [proposal] Pruning
up the CVS tree for real)
Posted by Gianugo Rabellino <gi...@apache.org>.
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)
+1
> - 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)
+1
> - 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)
+1. But what happens from there on? No more branching, I assume, just
tagging as 2.0.x release happens. Right?
> - 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)
Here I'm not sure. ATM I'd rather have the latest cocoon version in a
repository such as plain "cocoon" (think CVS HEAD). In this Cocoon
lifecycle it represents 2.1. When we release 2.1, we can move this repo
to cocoon-2.1 and start using it (with tagging, no branching) for 2.1.x
releases, while "cocoon" would become the 2.2 repo. Isn't it cleaner
from a logical POV?
> I would like to make my point by simply showing how checking out or doing an
> update on new copies of the repository is _much_ faster than the old
> ones... We don't have branches and we don't have empty dirs to process in
> those...
Yes. Too bad we have to resort to a hack (mimick branches via
duplicating repositories) instead than relying on the SCM internals.
Ciao,
--
Gianugo "eagerly waiting for subversion" Rabellino
Pro-netics s.r.l.
http://www.pro-netics.com
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
RE: [PROPOSAL] New CVS Repository Names (Was: Re: [proposal] Pruningup the CVS tree for real)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
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
[PROPOSAL] New CVS Repository Names (Was: Re: [proposal] Pruning
up the CVS tree for real)
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 27/2/03 10:28 am, "Carsten Ziegeler" <cz...@s-und-n.de> wrote:
> So can we then simply start a proposal on how to name the repositories?
+1! There we go (from yesterday)
- 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)
- 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)
- 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)
I would like to make my point by simply showing how checking out or doing an
update on new copies of the repository is _much_ faster than the old
ones... We don't have branches and we don't have empty dirs to process in
those...
Pier