On 27/2/03 10:51, "Carsten Ziegeler" <[EMAIL PROTECTED]> 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
