[Python-Dev] Mercurial workflow question...
trent at snakebite.org
Fri Dec 14 02:21:24 CET 2012
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
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.
More information about the Python-Dev