Handling thirdparty 'vendor' branches

[Giorgos Keramidas]

On Fri, 11 Jul 2008 11:49:35 +0300, Dov Feldstern <dfeldstern at fastimap.com> wrote:
> Giorgos Keramidas wrote:
>> I'm trying to understand how we can create 'vendor branches' in
>> Mercurial.
>
> [...]
>
>> That's amazing.  It's _exactly_ what I wanted Hg to do.  To track the
>> rename of the vendor code only in the 'target' tree, and then DTRT when
>> merges need to touch/affect files in the target tree.  Fantastic :)
>
> This really is very cool! :)
>
>> Now what?
>> =========
>>
>> Now my main concerns about this are:
>>
>>   * Does this look like a reasonable way to handle thirdparty
>>     code imports?
>>
>>   * Am I missing something that may potentially mess things up,
>>     if I keep pulling and merging from a 'clean vendor branch' of
>>     imports like this?
>>
>>   * This seems to work nicely with just one thirdparty component,
>>     but do you see any potential pitfalls when pulling and
>>     merging dozens of thirdparty components?
>
> I don't see any outright problem with this. However, I'm wondering if
> having all of these components tied together in one repository is
> desirable. Have you considered using hgforest instead?

I have looked at hgforest.  It provides some tools to work with multiple
Hg repositories, but the various `parts of the big picture' have a
history of their own.

Having a single tree means I can tag the repository in one place, with
one commit, and it's easy to look at the full history of all the various
parts.  The separate 'vendor branch' repository tracks only the vendor
code, so there's still a single place to look for 'vendor' changes.

> Additionally, we often need to "mix and match" various versions of the
> components. For example, on one branch, say for feature X, consisting
> of components A, B and C, we require versions A.1, B.1 and C.2; and on
> another branch, for feature Y, we use A.2, B.2 and C.2; etc. So it's
> much more convenient to be able to choose a specific version of each
> component independently of the versions chosen for the other
> components. This becomes much more difficult with a monolithic
> repository like the one you described above.

Agreed.  I am just trying to find a way that allows this (pulling only
the changes from 'vendor' trees that I want), but also tracks the time
of the imports in the 'master tree'.  With a forest the information of
what components one needs is 'external', saved somewhere else :/