- 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
