1.0 approaches

[Stuart W. Marks]

Adrian Buehlmann wrote:
> 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.

I too find the named branches feature very useful. Fortunately, Matt has 
already said that this feature won't be removed.

Nonetheless, there is clearly a problem with named branches. Case in point is 
another thread on the Mercurial list right now, "Mercurial tip not visible," 
involving a new user who has apparently confused himself because he has two 
repos (one of which he calls a "branch") each of which has two branches:

http://www.selenic.com/pipermail/mercurial/2008-February/017005.html

Part of the confusion here is that there is some material still out there that 
refers to separate repos as "branches":

http://www.selenic.com/mercurial/wiki/index.cgi/QuickStart

http://www.selenic.com/mercurial/wiki/index.cgi/FAQ#head-d38f596e5287494c33a9a312d3a895d5ab581905

The problem here is that the sort of "branch" created by "hg clone" is 
completely different from the "branch" created by "hg branch; hg commit".

Personally I'd prefer that we completely stamp out the use of the term "branch" 
to refer to the use of separate repositories. I can take a shot at cleaning up 
the above references if people agree.

s'marks