cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Hochsteger <>
Subject Re: Moving to subversion - volunteers?
Date Mon, 10 May 2004 19:55:38 GMT

Upayavira wrote:

> Nicola Ken Barozzi wrote:
>> Carsten Ziegeler wrote:
>>> We agreed that we move to subversion as soon as possible.
>>> Next friday we will (hopefully) release 2.1.5, so we
>>> should move right after the release.
>>> Any volunteers for doing this?
>> Err... what should we actually do?
>> I mean, let's say that we have decided that the format will be:
>> /cocoon/ <- this is the repository
>>   /2.0/
>>     /trunk/  <- trunk of 2.0
>>     /tags/   <- tags of 2.0
>>   /2.1/
>>     /trunk/  <- trunk of 2.1
>>     /tags/   <- tags of 2.1
>> IIUC we just need to ask infrastructure to run cvs2svn to the 
>> cocoon-2.1 and cocoon-2.2 repos and put them under "cocoon" as 2.1 and 
>> 2.2.
> Personally, I would leave 2.0 as is, and then:
> /cocoon/
>  /trunk/ <- current trunk
>  /tags/new-kernel/ <- current 2.2 code

Could it be, that you rather meant the following:
  /trunk/ <- current trunk (same as HEAD on CVS)
  /tags/ <- Tags on specific Milestones and Releases
  /branches/ <- Branches of the cocoon repository
  /branches/2.1/ <- Cocoon 2.1 branch
  /branches/new-kernel/ <- current 2.2 code

The following pages cover especially repository organization, branching
and merging very well:

For all CVS users which are not yet familar with Subversion I'll
recommend the following link (Subversion for CVS Users):

> I would do it this way as, if we are to follow our new versioning 
> scheme, we cannot identify the new kernel with the version 2.2, so we 
> shouldn't use version numbers in our repository names. We should use 
> 'feature names' in our branches/tags. E.g. Forrest has its 'copyless' 
> branch. So we should have a 'new kernel' branch.

This sounds good to me.

But version numbers should of course be used for Tags (which means a
certain unmutable release) or branches of already released new
major/minor versions where other maintenance releases may follow.

Branches for experimental things (like the new-kernel branch) should
then be merged back to the trunk again, when it is decided to base
further development on it.

> Regards, Upayavira
> /cocoon


View raw message