Branches are Bad? (was: Re: What are the strengths of Mercurial for you?)

Paul Franz theandromedan at gmail.com
Sun Jan 11 21:42:45 UTC 2009



Sean Russell wrote:
> Doug Philips wrote:
>   
>> On or about  Friday, January 09, 2009, at 02:17PM, John D. Mitchell indited:
>>   
>>     
>>> (D) Branches
>>>       - I think they are a mistake to have in Hg. Partly it's the  
>>> focus issue, partly they exist because of other missing capabilities  
>>> such as integral sub-repos, shallow/partial clones, and cherrypicking,  
>>> and of course partly because there are so many people "stuck" in the  
>>> Centralized SCM mindset.
>>>     
>>>       
>> Since branching happens with distributed version control, I am guessing you really mean "named branches?"
>> For what my team uses them for(1) none of the "missing capabilities" would make any difference.
>> Could you elaborate a bit more on the exact problem/issue you have?
>>   
>>     
> I'll provide a counter-example, of where cloning-as-branching has issues.
>
>     1047 % time hg clone scout scout2
>     updating working directory
>     6171 files updated, 0 files merged, 0 files removed, 0 files unresolved
>     hg clone scout scout2  16.11s user 8.22s system 10% cpu 3:42.14 total
>
> So this is nearly 4 minutes to clone a repository, not to mention the 
> time and effort of having to create and configure a new project in 
> Eclipse for every clone.  The VCS should not be an impediment to 
> development; this is why _we_ use named branches.
>
> --- SER
>
>   
Also, the one thing that I am used to in my VCS is the ability to see 
the merges (at work I use ClearCase). In the case of Hg that means 
seeing what the parents are. This is critical with seeing that people 
have merged changes forward from one release branch to another.

Also, something to keep in mind. Most people that are coming to 
Hg/Git/Bzr are coming from a traditional VCS system where feature and 
release branches are the norm.

Paul Franz




More information about the Mercurial mailing list