merging default into stable

[Adrian Buehlmann]

On 21.01.2010 00:58, venizio krups wrote:
> On Wed, Jan 20, 2010 at 5:41 PM, Adrian Buehlmann <adrian at cadifra.com> wrote:
>> On 20.01.2010 21:46, Matt Mackall wrote:
>>> On Wed, 2010-01-20 at 11:43 -0500, venizio krups wrote:
>>>> hello list,
>>>>
>>>> at work we run one repo with two named branches: default, and stable,
>>>> and the workflow is similar to that of mercurial main tree. bugfixes,
>>>> and known to be stable changes, go into the stable branch which then
>>>> gets merged into default. we are now ready for the next major release
>>>> which brings me to my question.  would it be better to merge default
>>>> into stable, or to just tag default as released, and re-restart the
>>>> stable branch later on when needed?
>>>
>>>> what approach will mercurial take?
>>>
>>> Good question. As part of our time-based release process, after we
>>> freeze the code base, all work will take place on the stable branch. So
>>> entering the code freeze, I'll probably merge default into stable. Then
>>> for two weeks, we'll work on the stable branch, then tag 1.5. The first
>>> non-development check-in post-1.5 will restart the default branch at the
>>> 1.5 tag.
>>>
>>
>> Last time this question came up on TortoiseHg, I think I voiced for
>> having a uninterrupted chain of changesets on default, linking through
>> first parents back to the root.
>>
>> Not having a default branch during some nodes of history seems odd
>> to me.
>>
>> Problem is: I can't explain why.
> 
> hello,
> 
> i suppose because default has always been there.  :)
> 
> would you mind explaining your approach a bit more?  not sure i follow
> the "linking through first parents back to root" part.

A changeset has one or two parent changesets (its ancestors): the
first and the second parent. If the cset is not a merge, then you
only have a first parent.

There are two models to use the default/stable pattern:

A) don't use named branches: use a 'default' repo and a 'stable' repo
B) use named branches 'default' and 'stable' in a single repo

Mercurial switched from A to B for its own development.

With method A, things are symmetric: The stable repo can follow the
default repo for a period of time, so they are the same during that
period (during freeze, before release).

With method B, there is a forced asymmetry: one main chain of history nodes
has the branch name 'stable' and the other 'default'. So default
cannot follow stable anymore, because there is an inherent difference:
branch names. Branch names are now part of history.

In the named branch model, you normally "are on" a branch and merge the
other into it: e.g. you are on branch 'default' and merge 'stable' into
it. The branch you "are on" is the first parent of the working
directory if you do a merge. The branch which is merged-in is the
second parent of the merge.

If you want to follow the default branch back through history to the
root changeset, I suspect there could be a potential benefit not having
to travel back through 'stable' land to reach the root node.

Or in other words: I see it as a complication having to travel back
through 'stable' land to reach the root of 'default' land.
Interrupted 'default' history. There are two or more disconnected
sets of 'default' nodes.