[prev in list] [next in list] [prev in thread] [next in thread]
List: python-dev
Subject: Re: [Python-Dev] Mercurial conversion repositories
From: Brett Cannon <brett () python ! org>
Date: 2011-02-26 21:37:04
Message-ID: AANLkTi=oWYGdHW-jifqFfS6PAY6oKcTxNz+1MT4Kv5ic () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Sat, Feb 26, 2011 at 13:30, Barry Warsaw <barry@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.
[Attachment #5 (text/html)]
<br><br><div class="gmail_quote">On Sat, Feb 26, 2011 at 13:30, Barry Warsaw <span \
dir="ltr"><<a href="mailto:barry@python.org">barry@python.org</a>></span> \
wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex;">
<div class="im">On Feb 26, 2011, at 12:09 PM, Brett Cannon wrote:<br>
<br>
>For other people's benefit, LoD == line of development (I think).<br>
<br>
</div>Yes. It's just a word that isn't intimately tied to the \
implementation<br> details of a specific dVCS.<br>
<div class="im"><br>
>> I clone the remote repository using the command in the devguide, so I \
now<br> >> have<br>
>> a 'cpython' directory containing the history of all LoDs, but with \
a<br> >> working<br>
>> directory that reflects the 'default' LoD. Now, in the parent \
of<br> >> 'cpython', I<br>
>> do the following to get my separate-directory-LoDs:<br>
>><br>
>> $ hg clone -u 2.6 cpython py26<br>
>> $ hg clone -u 2.7 cpython py27<br>
>> # repeat and rinse for all other active LoDs<br>
>><br>
>><br>
>That's one way of doing it.<br>
<br>
</div>I'm sure there are many different ways of setting things up. I am totally \
in<br> favor of the devguide documenting and encouraging one particular way, and \
I'm<br> sure Mercurial will prove to be a flexible tool that can conform to \
user's<br> preferences rather than the other way 'round.<br>
<div class="im"><br>
>> (Aside: that cpython directory still bugs me. It doesn't naturally \
reflect<br> >> a<br>
>> LoD, so why do I have to stare at it? Yes, I can make it play double \
duty<br> >> by<br>
>> naming it "3.3" or whatever and updating it to the 3.3 LoD, but \
that feels<br> >> artificial.)<br>
>><br>
>It's a clone repository of CPython; the name makes perfect sense. You are<br>
>focusing on what the repository happens to be updated to ATM, not the fact<br>
>that the repository itself represents any and all LoDs.<br>
<br>
</div>No, I get all that. I'm just not sure why I should care where all the \
history<br> is stored. I'm not actually going to do any coding in the cpython \
directory,<br> so it just seems like a wart I have to carry around. But as I said \
before,<br> this is the Mercurial Way, so be it.<br>
<div class="im"><br>
>> Now I want to synchronize my local py27 directory with the state of that<br>
>> LoD<br>
>> on <a href="http://python.org" target="_blank">python.org</a>. This is a \
two step process:<br> >><br>
>> $ cd py27 # now I want to synchronize<br>
>> $ (cd ../cpython && hg pull)<br>
>> $ hg pull -u<br>
>><br>
>> Editing hgrc to point to <a href="http://hg.python.org" \
target="_blank">hg.python.org</a> means the sync-to-remote-master<br> >> \
operation is one command.<br> >><br>
>> I could do this:<br>
>><br>
>> $ cd py27 # now I want to synchronize<br>
>> $ hg pull -u ssh://<a href="http://hg@hg.python.org/cpython" \
target="_blank">hg@hg.python.org/cpython</a><br> >><br>
>> but I'm not going to remember that url every time. It wouldn't be \
so bad<br> >> if<br>
>> Mercurial remembered the pull URL for me, as (you guessed it :) Bazaar<br>
>> does.<br>
>><br>
><br>
>So does Hg: simply edit your .hgrc to have it both pull and push to the same<br>
>URL.<br>
<br>
</div>Right, see my follow up to RDM.<br>
<div class="im"><br>
>Or you can save yourself some trouble, and simply clone the repository at a<br>
>specific branch:<br>
><br>
> hg clone ssh://<a href="http://hg@hg.python.org/cpython#2.7" \
target="_blank">hg@hg.python.org/cpython#2.7</a><br> ><br>
>I believe that might even strip out other history outside the scope of the<br>
>branch.<br>
<br>
</div>That might be a better way if it doesn't slurp down the entire \
repository<br> history.<br>
<div class="im"><br>
>> >Anecdote: I migrated from Subversion to Mercurial a few years ago, \
and<br> >> >found Mercurial branches very intuitive. When I saw mentions \
of Bazaar<br> >> >branches I was driven nuts by (what I saw as) the \
conflation between a<br> >> >branch and a clone. Later I understood how it \
made sense from the<br> >> >perspective of Bazaar, so I shifted my judgment \
from "insanely<br> >> >confusing" to "a particular choice that I don't \
approve" <wink>.<br> >><br>
>> That's funny because to my eyes, Mercurial conflates \
"branches" and<br> >> "clones".<br>
>> Why a clone operation should give me the history for all<br>
>> lines-of-development<br>
>> inside a working directory for one "arbitrary" one strikes me as \
bizarre<br> >> (pardon the pun :).<br>
><br>
>Because Hg views a clone as that: a clone of the entire repository. A branch<br>
>just happens to be a part of the repository. And because it is the entire<br>
>repository it has to have you point somewhere, so it goes with default since<br>
>a lot of people never even work somewhere other than on default.<br>
<br>
</div>Yep, I get all that. It's Mercurial's model of the world.<br>
<div class="im"><br>
>Yes, fun isn't it? Makes me that much more glad I don't have to care \
about<br> >other DVCSs anymore; make the decision of which one to go through \
was<br> >painful partially for this reason.<br>
<br>
</div>Lucky you! I interact with tons of projects, so I still have to deal with<br>
everything from CVS to git. This will be my first serious foray into hg, and<br>
for that I'm glad. And really, *any* dVCS is better than a non-dVCS, so \
I'm<br> really happy this is finally happening, despite any initial grumbling \
you're<br> reading into my posts. :)<br>
<div class="im"><br>
>> >> I'll have to remember that 'hg pull' does not update \
the working copy by<br> >> >> default,<br>
>> ><br>
>> >That pull does not update is a feature: The operation between a \
remote<br> >> >repo and the local repo (the .hg directory) is separate from \
the<br> >> >operation from the local repo to the working directory. When \
you know<br> >> >that you want pull + update (like when you have a clean \
working<br> >> >directory), you use "hg pull -u". (I don't like the fetch \
command.)<br> >><br>
>> Sure, I get that. Again, this feature appears odd because I have the \
full<br> >> history of all LoDs embedded in a working directory of a single \
LoD.<br> ><br>
>Not single, _current_. I know you don't like the whole svn switch \
approach<br> >that this is like, but Hg is very much about "don't forget \
a thing", which<br> >is why you need to view a clone as a clone repository \
that you are choosing<br> >to view in a certain way at any moment in time instead \
of as a single branch<br> >that just happens to be carrying around the weight of \
other branches.<br> >Totally different approaches to VCS.<br>
<br>
</div>No really, I do get all that! I just don't like it much. Maybe \
it'll grow on<br> me though.<br>
<div class="im"><br>
>> I very rarely want to do that. It's more common (but still, IME not \
*that*<br> >> common) to commit the changes to just a few files at a time. \
One thing<br> >> Bazaar<br>
>> has that's very nice is the ability to "shelve" some changes \
for a time.<br> >> Let's say I'm working on a bug and I want to merge \
your changes in or sync<br> >> to<br>
>> the master. I can shelve some or all of my uncommitted changes, which<br>
>> saves<br>
>> them essentially out-of-the-way patch files, and then reverts my<br>
>> uncommitted<br>
>> changes. Unshelving then is the process of re-applying those patch \
files,<br> >> and<br>
>> yes, resolving conflicts.<br>
>><br>
><br>
>Hg's is the mq (Mercurial Queue) extension.<br>
<br>
</div>I think mq is more like quilt than shelve. The moral equivalents in \
Bazaar<br> would probably be the loom and pipeline extensions.<br>
<div class="im"><br>
>> This is also a great way to work when you want to do<br>
>> test-driven-development<br>
>> but need to do some exploration first. You can hack around non-TDD \
until<br> >> you're confident of your approach, shelve all your changes, \
then<br> >> incrementally<br>
>> apply them back as you write each test. I'm sure Mercurial has \
something<br> >> equally awesome lurking about. :)<br>
><br>
>They all have the same history from the Linux kernel for the patch queue<br>
>concept. I suspect it's pretty universally implemented, just with \
different<br> >command names (of course as gods forbid it be consistent).<br>
<br>
</div>Truth to that.<br>
<br>
I've often advocated for the big three to converge on repository format and<br>
wire protocol, and for them to innovate and differentiate on ui. The models<br>
might be different enough that you couldn't do it 100%, but the existence of<br>
mapping extensions (e.g. hg-git, bzr-hg) seems to imply that they're pretty<br>
darn close.<br>
<br>
If we had this, then all the hand wringing about which dVCS to choose would be<br>
essentially moot. You'd just pick the cli and gui clients you preferred.<br>
Really, sweating over the dVCS tool detracts from what you do care about,<br>
which is developing Python!</blockquote><div><br></div><div>There is hg-git, but that \
is hg on top of git. </div></div>
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-dev%40progressive-comp.com
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic