[Python-Dev] Hg: inter-branch workflow

[John Arbash Meinel]

-----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.

The cultural aspects of this also show up. Since we default to not
showing merge commits in 'bzr log' (or even when shown, they are shown
indented), there is less impetus to remove them by default.[2]

Guido mentioned that when he does long-term development, there are a lot
of advantages to having intermediate snapshots that he can roll back to,
which have questionable benefit in being in the final repository, since
some states were dead-ends that weren't pursued.

I certainly can understand that, but there is at least an argument that
preserving "this approach is a dead-end" also has some merit. If someone
comes to you and says "why didn't you implement it this way", you can
point to it and say "I tried, it didn't work". Which would also give
them a point to start if they really think it is an avenue to pursue
further.

I also remember something my Math teacher once said. That some of the
early proofs were so polished that nobody knew how to "reproduce" them.
Sure, anyone could follow the final proof and say "yes that is correct",
but nobody could *learn* from the proof, because it was missing those
human-level steps of intuition that helped understand *how* the proof
was developed, rather than just what the final state was.

That is not to say that the python.org primary repository should be a
teaching repository. However, I know that I'm personally quite curious
to see how Guido does his work. Insight into the minds of how
interesting people do interesting things and all.


Another key point of how tools influence and interact with culture.
Because bzr has a strong mainline bias, it leads to people interacting
with the tool differently, which strengthens and reinforces it. In
Mercurial, it would be trivial to add a "hg log --only-mainline" that
would always follow a specific parent and show that to you. However,
because Mercurial doesn't default to that view, people don't try to
preserve the mainline. For example, in these graphs are logically the
same, but result in a very different mainline view:


 A -- B -- C
       \    \
         D -- E

 A -- B -- C -- E
       \      /
         D --

If you consider D as "I did my work" and E as "and I integrated that
back into trunk".

If you merge the trunk revision C into E, and then push, you end up with
this graph:

 A -- B -- D -- E
       \      /
         C --

And suddenly the revision which was an "important" C change is now gone
on the mainline, and your personal "and I did D" is now a primary
revision. It doesn't matter much for a single revision D and C, but for
anything long lived, you end up with 100 Guido exploratory D revisions,
and some 50+ other python-dev super-stable trunk C revisions. And unless
the tool helps you preserve the ordering[3], you really don't want to
trying to treat them with different levels of authority. Hence, you tend
to collapse, because you really can only trust "E" to be a final stable
change.

John
=:->



[1] any copy of "trunk" has the same revision-id matching revno 1234,
    in Mercurial the numbers in 'hg log' correspond to the ordering in
    the physical repository, so depend on what order revisions were
    merged, etc.

[2] The downside is people having their work merged and then wondering
    "where did my commits go", and it looking like this guy named Patch
    was an extremely productive developer of Launchpad and Bazaar
    (Patch Queue Manager.)

[3] In Bazaar, you can set 'append_revisions_only = True' for
    integration branches. Which will refuse to push E if it would
    remove C as a mainline revision.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2Id5sACgkQJdeBCYSNAAMnjgCbBFiMtdkj8hvJ19dPn3Maz3Bo
TrwAmwfgmg0YMGaCPM+W+kAVVDVvrOlY
=6oWG
-----END PGP SIGNATURE-----