1.0 approaches

Vadim Lebedev vadim at mbdsys.com
Fri Feb 8 11:57:49 CST 2008


Stuart W. Marks wrote:
> 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.
>   
I'd suggest that cloned repos should be called ..... 'clones'


This will avoid confusion

Vadim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://selenic.com/pipermail/mercurial/attachments/20080208/7309e701/attachment.htm 


More information about the Mercurial mailing list