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