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

[Paul Boddie]

Skip wrote:
> Antoine wrote:
> > 94 changesets? If you want to avoid risking conflicts, you should "hg
> > pull" and "hg up" (or "hg pull -u") before you start working on
> > something (just like you "svn up"'ed before working on something).
>
> 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.

This is reminiscent of a message on the Mercurial mailing list recently, to 
which I responded with a question about people experiencing problems with 
Mercurial because they are used to file- or directory-specific operations in 
other systems, eliciting this reply:

"hg failed saying there were uncommitted changes (his source code
changes in another part of the tree). He didn't want to commit those
changes yet, they weren't finished. So he was stuck. To his mind, hg
was being stupid because it was getting in his way, "unnecessarily"
linking changes in the two sets of files together. The concept of a
revision being a state of the whole repo was alien. For most people
that concept came in with svn."

http://www.selenic.com/pipermail/mercurial/2011-March/037373.html

I've spent some time trying to tidy up and improve a document on the Mercurial 
Wiki about CVS-like working practices with Mercurial, and this might explain 
the differences in operation between CVS/Subversion and Mercurial, although 
it doesn't yet distinguish between the "narrow" file-specific commits you get 
in systems like CVS and Subversion, and the whole-project commits you get in 
systems like Mercurial:

http://mercurial.selenic.com/wiki/CvsLikePractice

(By the time you look at that page, I might have added something, though.)

I'm certainly no expert with Mercurial, and I've only been using it as a 
personal tool since the MoinMoin guys introduced me to it back at EuroPython 
2006, so even now the "right way" or "best practice" when it comes to 
propagating fixes between branches/clones is something I'm still figuring 
out, but having lurked on the recent python-dev threads and having read 
various queries on the Mercurial list over the past year or so, I get the 
impression that reaching for things like rebase and mq as the first choice to 
solve various workflow problems would get some blunt criticism on the 
Mercurial list.

That said, I can't readily find any good guides to managing a multi-branch 
project, but there seem to be some interesting techniques documented for some 
of the situations people are likely to encounter. For example:

http://mercurial.selenic.com/wiki/DaggyFixes describes pulling fixes 
selectively which I'll probably have to try on some personal project at some 
point

http://hginit.com/05.html describes the presumably common way of propagating 
fixes from stable branches to development branches

Certainly, the Python devguide is a nice piece of documentation, but I feel 
that there's an opportunity here to address some documentation issues that 
would also help others using and adopting Mercurial. For example, 
submitting "clean" changes to a project (that "collapse" thing) is a topic 
for a document that could usefully be written, containing some nice diagrams 
that explain the mechanism to newcomers, and it would surely benefit more 
than just the CPython development effort.

Paul