A variation of the Subversion "vendor branch" strategy for maintaining Cocoon releases under local version control.
This is a variation on the Subversion "vendor branch" strategy. It differs from the technique outlined in the book, in that we don't have a single main branch into which we merge vendor drops. We want to be able to assimilate a new Cocoon release without forcing all of our Cocoon application to upgrade, so we have a main branch for each Cocoon release that we bring in. That way, we can port each of our applications to a new Cocoon only if and when we need to do so.
I started using this system with the Cocoon 2.1.6 release and have been using it through 2.1.8.
mkdir /usr/local/Cocoon/drop
cd /usr/local/Cocoon/drop
src/
(note, this is right for 2.1.6, check it for each version; also, YMMV e.g. you might need to keep something in deprecated/
. Also, if you want to delete sources for blocks you know you will never, ever, need, you can do that here as well):
documentation/
samples/
resources/javadoc/
webapp/
everything except WEB-INF/
and sitemap.xmap
blocks/*/samples/
deprecated/
build.sh webapp
build.sh clean
setenv cocoon_svn file:///var/svn/repos/cocoon # (example setenv cocoon_new_release cocoon-2.1.6 # (example) cd /usr/local/Cocoon/drop svn import -m "Initial drop (cocoon-2.1.6)" $cocoon_svn/dist/$cocoon_new_release |
setenv cocoon_svn file:///var/svn/repos/cocoon # (example) setenv cocoon_new_release cocoon-2.1.7 # (example) setenv cocoon_prev_release cocoon-2.1.6 # (example) cd /usr/local/Cocoon/drop svn_load_dirs.pl -t $cocoon-new-release \ $cocoon_svn/dist \ current \ ./$cocoon-new-release |
svn copy -m "Create main branch" \ $cocoon_svn/dist/$cocoon-new-release \ $cocoon_svn/main/$cocoon-new-release cd /usr/local/Cocoon/builds # (create this if it's the first time) svn checkout $cocoon_svn/main/$cocoon-new-release cd $cocoon-new-release |
svn merge $cocoon_svn/dist/$cocoon-prev-release $cocoon_svn/main/$cocoon-prev-release |
Add 'em here, or email me --ML