[Cocoon Wiki] Update of "CocoonVendorBranch" by MarkLundquist

[Apache Wiki <wi...@apache.org>]

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}}}