[Python-Dev] Mercurial workflow question...

[Trent Nelson]

    Scenario: I'm working on a change that I want to actively test on a
    bunch of Snakebite hosts.  Getting the change working is going to be
    an iterative process -- lots of small commits trying to attack the
    problem one little bit at a time.

    Eventually I'll get to a point where I'm happy with the change.  So,
    it's time to do all the necessary cruft that needs to be done before
    making the change public.  Updating docs, tweaking style, Misc/NEWS,
    etc.  That'll involve at least a few more commits.  Most changes
    will also need to be merged to other branches, too, so that needs to
    be taken care of.  (And it's a given that I would have been pulling
    and merging from hg.p.o/cpython during the whole process.)

    Then, finally, it's time to push.

    Now, if I understand how Mercurial works correctly, using the above
    workflow will result in all those little intermediate hacky commits
    being forever preserved in the global/public cpython repo.  I will
    have polluted the history of all affected files with all my changes.

    That just doesn't "feel" right.  But, it appears as though it's an
    intrinsic side-effect of how Mercurial works.  With git, you have a
    bit more flexibility to affect how your final public commits via
    merge fast-forwarding.  Subversion gives you the ultimate control of
    how your final commit looks (albeit at the expense of having to do
    the merging in a much more manual fashion).

    As I understand it, even if I contain all my intermediate commits in
    a server-side cloned repo, that doesn't really change anything; all
    commits will eventually be reflected in cpython via the final `hg
    push`.

    So, my first question is this: is this actually a problem?  Is the
    value I'm placing on "pristine" log histories misplaced in the DVCS
    world?  Do we, as a collective, care?

    I can think of two alternate approaches I could use:

        - Use a common NFS mount for each source tree on every Snakebite
          box (and coercing each build to be done in a separate area).
          Get everything perfect and then do a single commit of all
          changes.  The thing I don't like about this approach is that
          I can't commit/rollback/tweak/bisect intermediate commits as
          I go along -- some changes are complex and take a few attempts
          to get right.

        - Use a completely separate clone to house all the intermediate
          commits, then generate a diff once the final commit is ready,
          then apply that diff to the main cpython repo, then push that.
          This approach is fine, but it seems counter-intuitive to the
          whole concept of DVCS.

    Thoughts?


        Trent.