[Python-Dev] Mercurial conversion repositories

[Brett Cannon]

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

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


There is hg-git, but that is hg on top of git.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110226/b405a77a/attachment.html>