===== Description =====
In CVS we use vendor branches to track upstream sources in our tree.  The vendor branch commit automatically "merges" updates to files we haven't touched in our HEAD branch, and leaves any conflicts to be handled in a later commit.

===== Current Implementation =====

===== SVN Implementation =====

Subversion does not need to provide particular support for vendor branches, they are treated as just another tree of files.  You can develop procedures to make it easier to manage third party code.  I have one set at
http://jc.ngo.org.uk/trac-bin/trac.cgi/wiki/ImportingIntoSubversion.  The Subversion book also has a [[http://svnbook.red-bean.com/nightly/en/svn.advanced.vendorbr.html|chapter dealing with vendor branches]].

===== Hg Implementation =====
The vendor branch feature is not really needed as there is nothing special about third-party code for Hg.  I'd expect people wanting to import new versions of contributed code in %%FreeBSD%% to do something like this, separated in two phases:

==== The initial import ====

<code>
cd /usr/src/contrib
tar xvfz foobar-1.0.tar.gz
mv foobar-1.0 foobar
cd foobar
hg commit -Am 'Import foobar 1.0.'
</code>

==== Updates ====

<code>
cd /usr/src/contrib
rm -rf foobar
tar xvfz foobar-1.1.tar.gz
mv foobar-1.1 foobar
hg commit -Am 'Import foobar 1.1.'
</code>

at this point, the ''%%hg commit%%'' command will find every new file, record all changed & deleted ones then commit it as a single changeset.

The other way would be to use Hg to generate a changeset between foobar 1.0 and 1.1, generate a bundle from the changeset (to record add/moved/deleted files which the default ''%%export%%'' command does not support) then apply this bundle to the "real" tree.

===== Git Implementation =====
The vendor branch feature was largely necessary for CVS, which makes dealing with branch merges difficult.  The process I would expect for our first FSF vendor branch update for gcc in git would be something like:

<code>
git-checkout master # 1
git-pull -s ours . FSF # 2
git-checkout FSF # 3
cd contrib/gcc
git-rm * # 4
tar -whatever ~/new-gcc.tar.gz
git-add * # 5
git-commit
git-checkout master
git-pull . FSF # 6
</code>

  - You're on the master branch
  - Create a commit with no changes and a parent including FSF, to mark that all merges from FSF are already done.
  - Switch to the vendor branch.
  - Remove the set of files from the last version from the vendor.
  - Add the new set of files.  Now, the index is updated with all the new gcc code.  Note that files that didn't change between 4) and now won't be considered updated.
  - Merge the new changes from the vendor branch.  This should basically apply the diff between the last version of gcc and this one.  The merge may fail if there are actual code conflicts, but this is more rare than with CVS.

And for later vendor branch updates, you would skip the first two steps.  Note that I haven't tested this exact set of commands, so I may have made mistakes in typing.

===== Monotone Implementation =====
**Supported**
(also see [[http://venge.net/monotone/wiki/FeatureVendorBranches|monotone:FeatureVendorBranches]])

Any branch can be used as a Vendor Branch.  Unlike CVS, vendor branches are not treated specially in [[/Monotone|Monotone]].

There are two aspects to this requirement that are often used together:
  * tracking "pristine" external sources in a separate branch
  * using the sources in such a branch as part of a larger derivative project