[Python-Dev] Mercurial conversion repositories

Éric Araujo merwok at netwok.org
Sat Feb 26 01:49:46 CET 2011


Hi,

Le 25/02/2011 20:43, Barry Warsaw a écrit :
> On Feb 25, 2011, at 06:40 PM, Adrian Buehlmann wrote:
> [snip]
>> Note that each of these branch clones will initially have your local
>> master repo as the default path [3,4]. If you'd like to have the default
>> push/pull path to point to ssh://hg@hg.python.org/cpython instead, you'd
>> want to edit the [paths] section in the .hg/hgrc file in each of the
>> branch repos.

I plan on having one clone per branch but pushing and pulling from only
one repository, so I don’t need to edit hgrcs.

> It does leave me with an empty 'master' directory that I basically won't
> touch, though I suppose I could hide it in a dot-filename.

Or have the master clone do double duty as the py3k clone.  (IOW, I have
2.7 3.1 3.2 py3k, I pull/push in py3k and also do merges and new
features in py3k).

> And I have to remember to fiddle with .hg/hgrc when I clone a new branch
> working directory, but I guess that's mostly a one-time cost.

You don’t, see above.  I’ve wanted to tell you something for a long
time: Mercurial branches are not at all like Bazaar branches.  See
http://mercurial.selenic.com/wiki/Branch and
http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/

Anecdote: I migrated from Subversion to Mercurial a few years ago, and
found Mercurial branches very intuitive.  When I saw mentions of Bazaar
branches I was driven nuts by (what I saw as) the conflation between a
branch and a clone.  Later I understood how it made sense from the
perspective of Bazaar, so I shifted my judgment from “insanely
confusing” to “a particular choice that I don’t approve” <wink>.

What I’m saying is that a lot of Bazaar terminology using “branch” does
not map as-is to Mercurial.  We clone a repo, we pull from a repo/clone,
we have named branches (e.g. 3.2) in a repo, we have unnamed branches on
one named branch.  I think you know that already, since you went from
using Bazaar terms applied to Mercurial to mixing terms from both
(“clone a new branch working directory” → “clone a repo”, probably).  I
salute your willingness to learn Mercurial, considering how fluent (and
fluffly) you appear to be with Bazaar.

> I'll have to remember that 'hg pull' does not update the working copy by
> default,

That pull does not update is a feature: The operation between a remote
repo and the local repo (the .hg directory) is separate from the
operation from the local repo to the working directory.  When you know
that you want pull + update (like when you have a clean working
directory), you use “hg pull -u”.  (I don’t like the fetch command.)

> and eventually I'll figure out the whole merge thing.

Without anything specific, I’ll point to some resources:
Short tuto: http://hginit.com/04.html
Concepts and examples: http://mercurial.selenic.com/wiki/Merge
Longer narratives:
http://hgbook.red-bean.com/read/a-tour-of-mercurial-merging-work.html
http://hgbook.red-bean.com/read/managing-releases-and-branchy-development.html

> One immediate thing that I'm missing from Bazaar is that 'bzr commit' invokes
> my editor and always shows me a 'diff -u' in the commit message buffer.  This
> is incredibly handy because I don't have to remember to do the diff in a
> different window, and I always have all the information I want right there to
> craft the commit message.

You speak to my heart, sir.  In your ~/.hgrc, under the section [ui],
set “editor = path/to/mercurial/source/hgeditor” and enjoy your diffs.
I use it and love it.

If you want to commit a subset of your local changes, I use
http://mercurial.selenic.com/wiki/CrecordExtension , a curses-based diff
selection UI that works like a charm.

Kind regards,
your friendly Mercurial whippersnapper


More information about the Python-Dev mailing list