cocoon-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Cocoon Wiki] Update of "CocoonVendorBranch" by MarkLundquist
Date Tue, 06 Jun 2006 15:14:41 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Cocoon Wiki" for change notification.

The following page has been changed by MarkLundquist:
http://wiki.apache.org/cocoon/CocoonVendorBranch

------------------------------------------------------------------------------
  = Abstract =
  A variation of the Subversion "[http://svnbook.red-bean.com/en/1.0/ch07s04.html vendor branch]"
strategy for maintaining Cocoon releases under local version control.
  = Motivation =
-  1. Control of local modifications (patches, additions to lib/optional and lib/local)
+  1. Control of local modifications (patches, additions to lib/local)
   1. Being able to easily see what changed from release to release
-  1. Import into the repository only what we need for production builds (no samples or docs)
+  1. Import into the repository only what we need for production builds: selected blocks
only, no samples or docs.
- = Caveat emptor :-) =
- I've set this up for myself, imported the first drop (Cocoon 2.1.6), and controlled some
local mods.  The phase where I merge in the next drop has not been tested yet.  When Cocoon
2.1.7 hits, I'll do it and fix any errors in this note.
  = Overview =
- This is a variation on the Subversion "[http://svnbook.red-bean.com/en/1.0/ch07s04.html
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 preserve the
"awareness" of each project on the version of Cocoon that it requires, so we have a main branch
for each Cocoon release that contains our local mods.
+ This is a variation on the Subversion "[http://svnbook.red-bean.com/en/1.0/ch07s04.html
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.
  = Details =
   1. {{{mkdir /usr/local/Cocoon/drop}}}
   1. {{{cd /usr/local/Cocoon/drop}}}

Mime
View raw message