[Python-Dev] Hg: inter-branch workflow

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 3/22/2011 3:22 PM, Barry Warsaw wrote:
> On Mar 22, 2011, at 12:07 PM, Adrian Buehlmann wrote:
> 
>> 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'.
> 
> I think that's different than what John was describing, or perhaps Python's
> use of it has the effect of being different.  IIUC, in Mercurial, within the
> default branch there's no clear "main line" of development assigned to a path
> within the DAG.  All paths are created equal, so it's not possible to
> e.g. have log or bisect suppress one path containing feature sub-commits from
> the point of departure to the point of recombination (merge).
> 
> -Barry

If you think of "mainline" as "trunk" or "master", then yes, Mercurial's
concept is "default".

If you think of "mainline" as a series of commits in a linear sequence,
then there isn't specifically a "main" "line" in Mercurial's world view.

In Bazaar, the sequence of first-parents in the history of a branch's
tip is considered special. Based on the concept that:

 cd me
 bzr merge ../you
 bzr commit -m "I merged you"

Is not the same *social* thing as:

 cd ../you
 bzr merge ../me
 bzr commit -m "You merged me"

Logically, the contents of the tree should be the same. The name of the
person doing it is often different. If you have "blessed branch"
approach to development (which almost all projects do at some level or
other) then merging something into the "blessed branch" is not the same
as merging the "blessed branch" into your personal branch.

For python, the "blessed branch" is http://hg.python.org/cpython.

Consider, if someone merges/pushes a change to that branch, it has very
different social consequences than if someone merges that branch into
their own feature branch. Namely, it is going to be part of the next
released tarball.


Note that hg does distinguish it a little bit. If you look here:
http://hg.python.org/cpython/graph

There is a clear separation of what was merged into the line on the
left, versus what was committed elsewhere. However, there is no
distinction on:
http://hg.python.org/cpython/shortlog

Note also that because 'hg log' doesn't default to only showing you
things on a given branch, you can end up with log views like this:
http://hg.python.org/cpython/graph/693415328363

Where "Relax timing check" has nothing to do with "Issue #10833", but
because the data in the repository has Relax Timing Check placed after
Issue #10833 physically on disk, they end up both getting shown in the
log view.

It certainly is much worse in
http://hg.python.org/cpython/shortlog/693415328363

Where there is no way to tell that the revisions are unrelated, and just
happen to physically reside in same repository.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2Iu5kACgkQJdeBCYSNAAMVQACgpGd53yMnQBjJXuoVLElxC6qN
OqwAmwTdxjIS5tjkf0+iK62DvT/uPLdz
=1YLF
-----END PGP SIGNATURE-----