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