named branches vs. seperate repo for vendor branch
Giorgos Keramidas
keramida at ceid.upatras.gr
Wed Nov 24 08:55:09 UTC 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