named branches vs. seperate repo for vendor branch

[Martin Geisler]

Hans Meine <meine at informatik.uni-hamburg.de> writes:

> Op den Dingsdag 23 November 2010 Klock 08:34:52 hett Dirkjan Ochtman
> schreven:
>> On Tue, Nov 23, 2010 at 01:37, Neal Becker <ndbecker2 at gmail.com> wrote:
>>
>>> 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?
>>
>> hg clone repo#upstream
>>
>> With the obvious difference that the resulting repo will have
>> "upstream" in the branch field on every cset.
>
> Does that work if you branch the vendor branch off 'default'?

It works in the sense that you get all the changesets on the vendor
branch, plus of course all the ancestor changesets on 'default'. You can
just ignore those, I think.

> I don't think so, but that's how I interpret Martin's drawings here:

>   http://bitbucket.org/mg/mercurial-talk/downloads/vendor-branches.pdf

> For this use case, it would help to "hg update null" before creating
> the vendor branch. (Martin, do you want to change your presentation?
> Alas, it would make it less simple to understand..)

No, I don't want to branch off the null revision -- I think it's quite
normal that the vendor branch is anchored at a revision on 'default'.

> If you really want to share the vendor branch between multiple
> projects, I think I would use a subrepo. OTOH, the vendor branch might
> be project- specific anyway.

Using a subrepo is another possibility.

-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://mercurial.aragost.com/kick-start/