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

[Nicola Ken Barozzi <ni...@apache.org>]

Morrison, John wrote, On 27/02/2003 13.27:
>>From: Pier Fumagalli [mailto:pier@betaversion.org]
...
>>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...
> 
> *Definitely* works for me :)

Yeah, seems ok. BTW, IIUC isn't it a bit similar to how SVN will work... 
that is, aren't branches clever copies of the head in another dir?

BTW, I read a bit at how SVN is engineered, and it's incredible. It uses 
Apache for connections, a DB for backend... the level of reuse seems 
really high, as well as the flexibility. Really clever.
Flexibility without the syndrome? ;-)

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------

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

[Pier Fumagalli <pi...@betaversion.org>]

On 27/2/03 12:50, "Nicola Ken Barozzi" <ni...@apache.org> wrote:
> Morrison, John wrote, On 27/02/2003 13.27:
>>> From: Pier Fumagalli [mailto:pier@betaversion.org]
> ...
>>> 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...
>> 
>> *Definitely* works for me :)
> 
> Yeah, seems ok. BTW, IIUC isn't it a bit similar to how SVN will work...
> that is, aren't branches clever copies of the head in another dir?

Awww... C'monnn... You spoiled the surprise... It is in fact what happens
with SVN... You don't tag, you don't branch, you always and only do
repository copies...

But it's not fair, I wanted to fix the process of development first and
_then_ tell that there is a tool allowing us to do it without all that crap
that CVS imposes us... (see below)

> BTW, I read a bit at how SVN is engineered, and it's incredible. It uses
> Apache for connections, a DB for backend... the level of reuse seems
> really high, as well as the flexibility. Really clever.
> Flexibility without the syndrome? ;-)

A little bit of syndrome, but just enough to make it look good on paper! :-)

On to Carsten who asked about above exactly...

On 27/2/03 12:30, "Carsten Ziegeler" <cz...@s-und-n.de> wrote:

>> 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?

We'll change the tool, and changing the tool means that we'll be dealing
with another beast, but as Nicola well said above, the process won't
change... We'll do repository copies for each version, but that is the way
in which subversion works...

BTW, SVN doesn't have a concept of "repository"... Like web-applications it
takes up an entire URL prefix and starts from there, so, probably, we'll end
up with something like http://cocoon.apache.org/repository (which is going
to be the only SVN "storage" for all of Cocoon), and under there we'll have
several "copies" of the code identified  (maybe) by version...

It is completely different in terms of tools and concepts, but the process
of repository copies is in there and is the only way to go with SVN...

    Pier