[Python-Dev] Mercurial conversion repositories

[Brett Cannon]

On Sat, Feb 26, 2011 at 10:08, Barry Warsaw <barry at python.org> wrote:

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

For other people's benefit, LoD == line of development (I think).


>
> 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
>
>
That's one way of doing it.


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

It's a clone repository of CPython; the name makes perfect sense. You are
focusing on what the repository happens to be updated to ATM, not the fact
that the repository itself represents any and all LoDs.


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

So does Hg: simply edit your .hgrc to have it both pull and push to the same
URL.

Or you can save yourself some trouble, and simply clone the repository at a
specific branch:

  hg clone ssh://hg@hg.python.org/cpython#2.7

I believe that might even strip out other history outside the scope of the
branch.


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


Because Hg views a clone as that: a clone of the entire repository. A branch
just happens to be a part of the repository. And because it is the entire
repository it has to have you point somewhere, so it goes with default since
a lot of people never even work somewhere other than on default.


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

Neither do I in an svn context and why Hg does let you check out just a
branch and have all pulls and pushes only go to that branch.


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

Yes, fun isn't it? Makes me that much more glad I don't have to care about
other DVCSs anymore; make the decision of which one to go through was
painful partially for this reason.


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


Not single, _current_. I know you don't like the whole svn switch approach
that this is like, but Hg is very much about "don't forget a thing", which
is why you need to view a clone as a clone repository that you are choosing
to view in a certain way at any moment in time instead of as a single branch
that just happens to be carrying around the weight of other branches.
Totally different approaches to VCS.


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

As I said above, use the #<branch> format and you skip this issue (I think).


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

Hg's is the mq (Mercurial Queue) extension.


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



They all have the same history from the Linux kernel for the patch queue
concept. I suspect it's pretty universally implemented, just with different
command names (of course as gods forbid it be consistent).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110226/46aacbc0/attachment-0001.html>