3rd party software customizations

[Becker, Mischa J]

From: mercurial-bounces at selenic.com [mailto:mercurial-bounces at selenic.com] On Behalf Of Cristiano Cortezia
Sent: Monday, April 16, 2012 5:29 PM
To: mercurial at selenic.com
Subject: 3rd party software customizations

Hi all,

I am trying to figure out the best strategy to version control a third party library, which is meant to be customized internally.

The main problem arises, of course, after the library provider releases a new version of their code, and these changes must be mixed to the local changes.

The "Vendor Branches" strategy purposed on the svn book (http://svnbook.red-bean.com/en/1.7/svn-book.html#svn.advanced.vendorbr<http://svnbook.red-bean.com/en/1.7/svn-book.html>) seems to make sense (I have some subversion background). I'm just not sure if this is the best approach on mercurial, or any other dvcs.

Do someone have a suggestion ? Any pointers are welcome.

I think the general consensus is to have two named branches, commit changes coming from the vendor to a vendor branch, and commit your changes to the vendor's code on a separate branch.

In the below example, rev 0 is the first version of the third party library, rev 1 & 2 are changes you made to the library, rev 3 is the next version from the third party, & rev 4 merges the third party's changes with yours.

vendor   0-----3
          \     \
default    1-2---4

When you get a new version from the vendor, it is real easy:
hg up vendor
#Replace the old vendor code with the new code
hg addremove
hg ci -m "Updated library to version 2.1"
hg up default
hg merge vendor

If you are heavily customizing the third party library or using it in multiple projects, I also suggest keeping these two branches in a repository all by themselves. This repository can then be included in your various projects as a subrepository.  See: http://mercurial.selenic.com/wiki/Subrepository

Mischa



  ________________________________

This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain information that is confidential and protected by law from unauthorized disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20120417/5fd0d058/attachment-0002.html>