named branches vs. seperate repo for vendor branch

[Kevin Bullock]

On 26 Nov 2010, at 2:32 AM, Martin Geisler wrote:

> Hans Meine <meine at informatik.uni-hamburg.de> writes:
> 
>> Op den Middeweken 24 November 2010 Klock 09:35:26 hett Martin Geisler 
>> schreven:
>>> Hans Meine <meine at informatik.uni-hamburg.de> writes:
>>>> Op den Dingsdag 23 November 2010 Klock 08:34:52 hett Dirkjan Ochtman
>>>> schreven:
>>>>> 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.
>> 
>> That's what I mean - it does not meet Neal's expectations:
>> 
>>> One other advantage to seperate repo is that if I ever want a repo
>>> that has just the vendor history [...]
>> 
>> But you wrote:
>> 
>>> 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'.
>> 
>> Yeah, I had a similar 'feeling' ("quite normal", more easy to grasp),
>> although technically it is wrong IMO. After all - you already pay
>> attention to merge only from vendor branch to 'default', so why should
>> the vendor branch contain a snapshot of the main project at all?
> 
> Yeah, good question... :-) I cannot come up with a good reason for
> including a snapshot either.

I can think of one: if the project is 'small enough', then snapshotting the whole project at a particular version of vendor sources doesn't cost much and results in a simpler workflow.

pacem in terris / mir / shanti / salaam / heiwa
pacem in terris / mir / shanti / salaam / heiwa
Kevin R. Bullock