merging default into stable

[Adrian Buehlmann]

On 21.01.2010 03:58, Greg Ward wrote:
> On Wed, Jan 20, 2010 at 8:00 PM, Adrian Buehlmann <adrian at cadifra.com> wrote:
>> 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.
> 
> But if you take the alternative approach -- stabilize on 'default' and
> rebranch 'stable' -- then you have a similar situation with 'stable',
> i.e. 'stable' is not a topologically connected subset of the graph.

Not necessarily so. You could apply my proposal for stable as well (have
first parent back-connected on stable).

But having a disconnected stable seems a lesser evil to me (compared to
having a disconnected 'default'), since most sane projects have at least a
default branch, and lots of projects don't need nor have any branches at
all (so they have no 'stable' branch).

> Maybe that's a good argument for having separate '1.4', '1.5', etc.
> branches.  ;-)

X.Y branches exhibit the problem that they become meaningless even
faster than the default/stable branch names of the default/stable
development pattern.

Imagine: you have a followup project Q (e.g. "Mercurial Plus") that wants
to reuse the repo of project P ("Mercurial") as a base.

The old X.Y branch names of P are thoroughly meaningless in Q, since Q
wants to define its own release namespace. E.g. the 1.3 release of
Q has nothing to do with the 1.3 of ancestor project P.

And no, branch closing does not really help, since it does not really
remove the old branch names (compare with removing tags).

If you can do with a default/stable development pattern on a project -- that
is, not having to bugfix more than one released version at the same time --
then doing X.Y named branches is just plain overkill and a needless proliferation
of branch names, polluting history forever.