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: /cocoon/ /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: http://svnbook.red-bean.com/svnbook/ch04.html http://svnbook.red-bean.com/svnbook/ch04s07.html
For all CVS users which are not yet familar with Subversion I'll recommend the following link (Subversion for CVS Users): http://svnbook.red-bean.com/svnbook/apa.html
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
Bye, Andreas.
