named branches vs. separate repo for vendor branch

[Becker, Mischa J]

>-----Original Message-----
>From: mercurial-bounces at selenic.com [mailto:mercurial-bounces at selenic.com] On Behalf Of Neal Becker
>Sent: Monday, November 22, 2010 4:38 PM
>To: mercurial at selenic.com
>Subject: named branches vs. seperate repo for vendor branch
>
>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?
>
>_______________________________________________
>Mercurial mailing list
>Mercurial at selenic.com
>http://selenic.com/mailman/listinfo/mercurial

As long as you never merge any other branch into upstream, all you have to do is clone the upstream branch.  i.e.

hg clone -b upstream repo-orig repo-upstream-only

Mischa Becker

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.