[Python-Dev] I am now lost - committed, pulled, merged, what is "collapse"?

[Nick Coghlan]

On Sun, Mar 20, 2011 at 5:05 AM,  <skip at pobox.com> wrote:
> Sorry, this workflow is still new and hugely confusing to me.  To make a
> simple edit to csv.rst I needed to do a couple pulls and merges, local
> commits, resolve the same conflict multiple times, get rebuffed when I first
> pushed because there was a tab in the file, and ask a question here.  If
> this is the typical route necessary to make even the simplest changes which
> would have been a single commit with svn, my already meager rate of
> contributions is likely to wither away to nothing.

Note that some of that isn't unique to the Mercurial transition
(specifically, the server side hook that complained about the
whitespace change existed in SVN as well).

One key difference that we could historically ignore with SVN is that
it would happily accept changes from an out-of-date working copy, so
long as the committed changes didn't alter any files that had also
been updated on the head. In practice, this *did* mean a lot of
commits did get rejected, since Misc/NEWS would often conflict.
Mercurial's changeset based view of the world means it wants to know
how the changesets relate to each other even when they affect
different files, unlike SVN which would happily do an implicit merge
(creating a state in the central repo that no developer has ever
tested locally).

So the full flow for a trunk commit in SVN was:

svn update
# change stuff
svn commit -m "Whatever"
# get rejected by server side hooks (e.g. changed files, bad whitespace)
make patchcheck # fix whitespace issues
svn update # get updated files
# Resolve any conflicts, rerun relevant tests
svn commit -m "Whatever"

Mercurial isn't really all that different, but it's distributed nature
means it want to keep track of even minor things like the local
whitespace fixes and the merger of your changes with the other changes
that were pushed since you started work. So the example above becomes
something like:

hg pull -u
#change stuff
hg commit -m "Whatever"
hg push
# get rejected by server side hooks (e.g. changed files, bad whitespace)
make patchcheck
hg commit -m "Fix whitespace"
hg pull -u
hg merge
# Resolve any conflicts, rerun relevant tests
hg commit -m "Merge with remote"
hg push

It definitely produces some additional noise on python-checkins, since
things that would normally have been resolved privately by the
developer before SVN accepted the commit are now being published to
the mailing list. To help with that, I've personally split my
python-checkins label into two: one which contains everything from the
list, and another which filters out any messages with "merge" in the
subject line.

You may also find "hg outgoing" useful, since that will tell you all
the changesets that a call to "hg push" will publish, rather than just
the latest changeset as shown by "hg heads".

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia