[Python-Dev] Mercurial conversion repositories

[Barry Warsaw]

On Feb 26, 2011, at 01:49 AM, Éric Araujo wrote:

>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.

So let's start from the basics.  I want separate working directories for each
active line-of-development (I'll use that term instead of "branch"),
e.g. working directories containing the tip of the 2.6 LoD, 2.7, 3.1, 3.2, and
3.3.  I will not be doing feature or bug development in any of these
directories.  They are purely for local tracking of the remote masters.  Thus,
I want to be able to synchronize any one of those LoDs against the remote
master with one command, like I would using Subversion's 'svn up'.

I clone the remote repository using the command in the devguide, so I now have
a 'cpython' directory containing the history of all LoDs, but with a working
directory that reflects the 'default' LoD.  Now, in the parent of 'cpython', I
do the following to get my separate-directory-LoDs:

$ hg clone -u 2.6 cpython py26
$ hg clone -u 2.7 cpython py27
# repeat and rinse for all other active LoDs

(Aside: that cpython directory still bugs me.  It doesn't naturally reflect a
LoD, so why do I have to stare at it?  Yes, I can make it play double duty by
naming it "3.3" or whatever and updating it to the 3.3 LoD, but that feels
artificial.)

Now I want to synchronize my local py27 directory with the state of that LoD
on python.org.  This is a two step process:

$ cd py27 # now I want to synchronize
$ (cd ../cpython && hg pull)
$ hg pull -u

Editing hgrc to point to hg.python.org means the sync-to-remote-master
operation is one command.

I could do this:

$ cd py27 # now I want to synchronize
$ hg pull -u ssh://hg@hg.python.org/cpython

but I'm not going to remember that url every time.  It wouldn't be so bad if
Mercurial remembered the pull URL for me, as (you guessed it :) Bazaar does.

>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>.

That's funny because to my eyes, Mercurial conflates "branches" and "clones".
Why a clone operation should give me the history for all lines-of-development
inside a working directory for one "arbitrary" one strikes me as bizarre
(pardon the pun :).  I get that for folks who like the "svn switch" method of
working on multiple LoDs, this probably makes a lot of sense.  I don't
personally like or trust that approach much though.

>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.

This is an inevitable problem with trying to converse fluently about three
major dVCSs and at least one or two other non-dVCSs.  They all use the same
words to mean vaguely similar things, but quickly get bogged down in the
implementation details assigned to those words.  It all makes perfect sense
when you've been immersed in those technologies, but it makes discussions and
comparisons exceedingly difficult.  I've no doubt it's doubly painful to many
people who have no prior experience with a dVCS.

(Aside: Bazaar could have potentially eased these folks transition because you
can use Bazaar just like you would Subversion - as a centralized VCS --
without stopping others from using it with full dVCS features on the same code
base.  I don't know if Mercurial offers the same flexibility.)

It's a little like trying to teach Python to a Java programmer.  "Object",
"Class", "Instance", "Import" all mean roughly similar things, which lulls you
into a false sense of understanding.  We learn by holding up the new to the
light of the familiar and looking for interference patterns. :)

>> 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.)

Sure, I get that.  Again, this feature appears odd because I have the full
history of all LoDs embedded in a working directory of a single LoD.  With the
arrangement I outlined above (which is independent of the dVCS backing it), it
makes no sense for each LoD working directory to contain all the history of
all the other LoDs.

In Bazaar, a "branch" is an independent LoD and it's "repository" contains
only its own history.  Sure, it might have identical history with other LoDs
up to the point of divergence, and I have ways to efficiently share that
history across multiple LoD working directories, but they are still separate
and I don't need them if I don't care about them.  With Mercurial, all history
for all LoDs in a repository always come along for the ride.

>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.

Great, I'll try that, thanks.  One thing Mercurial and Bazaar definitely share
is a wealth of magical awesomeness hidden in manpages, wiki pages, mailing
list posts, people's heads, configuration files, and source code. :)

>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.

I very rarely want to do that.  It's more common (but still, IME not *that*
common) to commit the changes to just a few files at a time.  One thing Bazaar
has that's very nice is the ability to "shelve" some changes for a time.
Let's say I'm working on a bug and I want to merge your changes in or sync to
the master.  I can shelve some or all of my uncommitted changes, which saves
them essentially out-of-the-way patch files, and then reverts my uncommitted
changes.  Unshelving then is the process of re-applying those patch files, and
yes, resolving conflicts.

This is also a great way to work when you want to do test-driven-development
but need to do some exploration first.  You can hack around non-TDD until
you're confident of your approach, shelve all your changes, then incrementally
apply them back as you write each test.  I'm sure Mercurial has something
equally awesome lurking about. :)

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110226/67324f4a/attachment.pgp>