[Python-Dev] Hg: inter-branch workflow

[Adrian Buehlmann]

On 2011-03-22 11:19, John Arbash Meinel wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 3/21/2011 9:19 PM, Barry Warsaw wrote:
>> On Mar 21, 2011, at 11:56 AM, Daniel Stutzbach wrote:
>>
>>> Keeping the repository clean makes it easier to use a bisection search to
>>> hunt down the introduction of a bug.  If  every developer's intermediate
>>> commits make it into the main repository, it's hard to go back to an older
>>> revision to test something, because many of the older revisions will be
>>> broken in some way.
>>
>> So maybe this gets at my earlier question about rebase being cultural
>> vs. technology, and the response about bzr having a strong sense of mainline
>> where hg doesn't.
>>
>> I don't use the bzr-bisect plugin too much, but I think by default it only
>> follows commits on the main line, unless a bisect point is identified within a
>> merge (i.e. side) line.  So again, those merged intermediate changes are
>> mostly ignored until they're needed.
>>
>> -Barry
> 
> Bazaar is, to my knowledge, the only DVCS that has a "mainline"
> emphasis. Which shows up in quite a few areas. The defaults for 'log',
> having branch-stable revnos[1], and the 'bzr checkout' model for
> managing a mainline.
> 

FWIW, Mercurial's "mainline" is the branch with the name 'default'. This
branch name is reserved, and it implies that the head with the highest
revision number from that branch will be checked out on 'hg clone'.

Which is why it makes sense to have something sensible on the default
branch in Mercurial repositories. Or inadvertent people may be surprised
when they clone ("After cloning, the files I have seem to be from a very
old state of the project, WTF?").

What's more, 'hg log' suppresses printing the line 'branch: default' for
changesets on that branch and commits after 'hg init' go into the
default branch if 'hg branch <name>' hasn't been used. So, the initial
branch name of a fresh working copy is 'default'.