There is, of course, a section on vendor branches in the book, but
since you're already using the terminology "vendor branch" I presume
you've already read that.
I keep vendor branches of several tools we use at work, like the
MediaWiki. I use the svn_load_dirs.pl script to keep /vendor/
mediawiki up to date with respect to the current released version of
MediaWiki. I also keep our version in /tools/mediawiki. Initially
this was created by copying the then-current version of /vendor/
mediawiki to /tools/mediawiki, and after that it has been kept up to
date by merging changes from /vendor/mediawiki into it. And I can
also apply any patches I want to /tools/mediawiki which are either
retained when upgrading to new official versions, or marked as
conflicts. Sometimes I report a bug and a fix, and apply the fix
directly to /tools/mediawiki, and when the next official version
comes around, they've fixed it in a different way, so I get a
conflict. In that case I can either deal with the conflict normally,
or I can first undo my local fix before merging in the new version to
avoid the conflict entirely.
I guess the bottom line is to keep a pristine copy of whatever you're
going to use as your baseline in /vendor/foo and then keep a copy
with your modifications and local patches somewhere else.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Mar 24 01:17:40 2006