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