[Python-Dev] Mercurial conversion repositories

[Barry Warsaw]

On Feb 26, 2011, at 12:09 PM, Brett Cannon wrote:

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

Yes.  It's just a word that isn't intimately tied to the implementation
details of a specific dVCS.

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

I'm sure there are many different ways of setting things up.  I am totally in
favor of the devguide documenting and encouraging one particular way, and I'm
sure Mercurial will prove to be a flexible tool that can conform to user's
preferences rather than the other way 'round.

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

No, I get all that.  I'm just not sure why I should care where all the history
is stored.  I'm not actually going to do any coding in the cpython directory,
so it just seems like a wart I have to carry around.  But as I said before,
this is the Mercurial Way, so be it.

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

Right, see my follow up to RDM.

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

That might be a better way if it doesn't slurp down the entire repository
history.

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

Yep, I get all that.  It's Mercurial's model of the world.

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

Lucky you!  I interact with tons of projects, so I still have to deal with
everything from CVS to git.  This will be my first serious foray into hg, and
for that I'm glad.  And really, *any* dVCS is better than a non-dVCS, so I'm
really happy this is finally happening, despite any initial grumbling you're
reading into my posts. :)

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

No really, I do get all that!  I just don't like it much.  Maybe it'll grow on
me though.

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

I think mq is more like quilt than shelve.  The moral equivalents in Bazaar
would probably be the loom and pipeline extensions.

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

Truth to that.

I've often advocated for the big three to converge on repository format and
wire protocol, and for them to innovate and differentiate on ui.  The models
might be different enough that you couldn't do it 100%, but the existence of
mapping extensions (e.g. hg-git, bzr-hg) seems to imply that they're pretty
darn close.

If we had this, then all the hand wringing about which dVCS to choose would be
essentially moot.  You'd just pick the cli and gui clients you preferred.
Really, sweating over the dVCS tool detracts from what you do care about,
which is developing Python!

-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/419bf994/attachment.pgp>