named branches vs. seperate repo for vendor branch

Giorgos Keramidas keramida at ceid.upatras.gr
Wed Nov 24 02:55:09 CST 2010


On Mon, 22 Nov 2010 19:37:36 -0500, Neal Becker <ndbecker2 at gmail.com> wrote:
> Continuing exploration of options for vendor branches.
>
> In the past, I've used a one repo for vendor code, and a seperate repo for
> my patches.  In my experience:
>
> pro: easy to understand
> con: to copy to another remote, I'd need to copy 2 repos
>
> Today I tried using named branches within a single repo to represent vendor
> code vs my patches.
>
> pro: 1 repo
> con: While the update procedure is similar, I find this more error prone.  I
> need to keep thinking about which branch I'm on before doing an operation.
>
> But I'm wondering about another aspect.  One other advantage to seperate
> repo is that if I ever want a repo that has just the vendor history, it's
> already right there.  So that raises a question.  Is there some way to
> obtain just the vendor repo with history using the named branch approach?
> That is, suppose the vendor branch is called 'upstream', while my patches
> are on default.  Can I produce a new repo that has only the vendor branch
> and no history of default?

Yes.  You just clone the named branch of the vendor out of the 'full'
repository as you would clone any other named branch:

    hg clone -b boost full-repo boost-repo

This will only pull the 'boost' branch from the full-repo, so you would
have the history of boost imports in one place.



More information about the Mercurial mailing list