Vendor Branching, Mercurial Style?

Question

The scene: A purchased web application, with regular updates from the vendor. We then, heavily customize the look and sometimes add our own functionality or fix a bug before the vendor gets to it. For version control, we have been using Subversion following their “Vendor Branch” model each time we received a new release. This has the added benefit that we have a, version controlled, vanilla copy of their system.

The problem: We would like to switch to Mercurial and will likely follow the stable/default branching pattern. Mercurial makes perfect sense if we were to only receive a single release from our vendor and start developing it from there. But, for whatever reason, I am having trouble wrapping my mind around how to handle future releases from the vendor.

The plea: Any help with “vendor branching” Mercurial style would be greatly appreciated.

Answer 1

Using named branches as you've described is a fine choice (though not the only choice), but I'd still suggest using a few separate clones at well known locations to facilitate this process. Pretending that http://host/hg/ is a hgweb (formerly hgwebdir) for your install (though ssh:// works great too, whatever), you'd have something like this:

• http://host/hg/vendor
• http://host/hg/custom

Two separate repos where data flow from vendor to custom but never the other direction. The named branch default would be the only one in vendor and in custom you'd have both default and stable.

When you got a new code drop from the vendor you'd unpack it into the working directory of the vendor repo, and then run:

hg addremove
hg commit -m 'new drop from vendor, version number x.x.x'

Your history in that vendor repo will be linear, and it will never have anything you wrote.

Now in your local clone of the custom repo you'd do:

hg update default     # update to the latest head in your default branch
hg pull http://host/hg/vendor   # bring in the new changes from vendor as a new head
hg merge tip          # merge _your_ most recent default cset with their new drop

And then you do the work of merging your local chances on default with their new code drop. When you're happy with the merge (tests pass, etc.) you push from your local clone back to http://host/hg/custom.

That process can be repeated as necessary, provides good separation between your history and theirs', and lets everyone on your team not responsible for accepting new code drops from vendors, to concern themselves only with a normal default/stable setup in a single repo, http://host/hg/custom.