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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
