Re: [PROPOSAL] New CVS Repository Names (Was: Re: [proposal] Pruning up the CVS tree for real)

[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] Pruning up the CVS tree for real)

[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