1.0 approaches

[Adrian Buehlmann]

On 08.02.2008 05:55, Brendan Cully wrote:
> On Thursday, 07 February 2008 at 18:49, Matt Mackall wrote:
>> There are still some areas with rough edges - named branches and case
>> sensitivity come to mind. Improvements there that aren't too invasive
>> will be considered, but these aren't currently going to be considered
>> showstoppers.
> 
> In my opinion, named branches in their current form do more harm than good.
> People use them expecting them to behave more like in-repository clones
> that they can play with and then drop, and usually become frustrated
> with them, but only after they've permanently cluttered their repositories.
> 
> They also interact badly with clone and older clients, as well as having
> more benign UI warts.
> 
> I'd be inclined to discourage their use strongly in 1.0 (maybe relegating 
> them to debugcommands) unless they are improved. I think they will tend to
> result in bad feelings, whereas most of the rest of mercurial is warm
> and fuzzy.

Removing "Mercurial named branches" would be somewhat of a surprise for me. 
We've just switched from Perforce to Mercurial and I've used Mercurial named 
branches to *name* major development lines in Mercurial the same way as we had 
them in Perforce (Please note that I'm aware that Perforce "branches" are not 
the same as Mercurial named branches. I've just used them in Mercurial to mark 
changesets).

For example in our project, I used the Mercurial "branch" name "default" *and* 
the Mercurial branch name "rel-1.3".

I do find it handy that I have *names* for them. We do have a main repository 
for product MP on our internal server. I first considered having two separate 
main repositories: one for the "default" or trunk development line and one for 
"rel-1.3" development. I then quickly realized that I would end having "rel-1.3" 
changesets in the default line repo anyway, because we do small fixes in the 
"branch" that has evolved the least and merge them into the default "branch". So 
I dropped the "separate main repositories" approach.

But we don't want to have trunk features in the rel-1.3 development line. And
having a name marker for changesets of major changeset subtrees is helpful.

Perhaps, it is just the name "branch" which confuses people? I see it more like 
an automatic tag, probably best used for major development lines. But I fail to 
see how exactly it does that much harm up to the point where a released feature 
which is in use should be removed. That ship has sailed anyway.