[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 20:09:58
Message-ID: AANLkTinq7svDrMK+M21-GrMB=ZjSByG-KmSd8_tYDofr () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Sat, Feb 26, 2011 at 10:08, Barry Warsaw <barry@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).
[Attachment #5 (text/html)]
<br><br><div class="gmail_quote">On Sat, Feb 26, 2011 at 10:08, 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 01:49 AM, Éric Araujo wrote:<br>
<br>
>Le 25/02/2011 20:43, Barry Warsaw a écrit :<br>
>> On Feb 25, 2011, at 06:40 PM, Adrian Buehlmann wrote:<br>
>> [snip]<br>
>>> Note that each of these branch clones will initially have your local<br>
>>> master repo as the default path [3,4]. If you'd like to have the \
default<br> >>> push/pull path to point to ssh://<a \
href="http://hg@hg.python.org/cpython" target="_blank">hg@hg.python.org/cpython</a> \
instead, you'd<br> >>> want to edit the [paths] section in the .hg/hgrc \
file in each of the<br> >>> branch repos.<br>
><br>
>I plan on having one clone per branch but pushing and pulling from only<br>
>one repository, so I don't need to edit hgrcs.<br>
<br>
</div>So let's start from the basics. I want separate working directories for \
each<br> active line-of-development (I'll use that term instead of \
"branch"),<br> e.g. working directories containing the tip of the 2.6 LoD, \
2.7, 3.1, 3.2, and<br> 3.3. I will not be doing feature or bug development in any \
of these<br> directories. They are purely for local tracking of the remote masters. \
Thus,<br> I want to be able to synchronize any one of those LoDs against the \
remote<br> master with one command, like I would using Subversion's 'svn \
up'.<br></blockquote><div><br></div><div>For other people's benefit, LoD == \
line of development (I think).</div><div> </div><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
I clone the remote repository using the command in the devguide, so I now have<br>
a 'cpython' directory containing the history of all LoDs, but with a \
working<br> directory that reflects the 'default' LoD. Now, in the parent \
of '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></blockquote><div><br></div><div>That's one way of doing it.</div><div> \
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex;"> (Aside: that cpython directory still bugs me. It \
doesn't naturally reflect a<br> LoD, so why do I have to stare at it? Yes, I \
can make it play double duty by<br> naming it "3.3" or whatever and \
updating it to the 3.3 LoD, but that feels<br> \
artificial.)<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex;"> <br>
Now I want to synchronize my local py27 directory with the state of that 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 \
if<br> Mercurial remembered the pull URL for me, as (you guessed it :) Bazaar \
does.<br></blockquote><div><br></div><div>So does Hg: simply edit your .hgrc to have \
it both pull and push to the same URL.</div><div><br></div><div>
Or you can save yourself some trouble, and simply clone the repository at a specific \
branch:</div><div><br></div><div> hg clone ssh://<a \
href="http://hg@hg.python.org/cpython" \
target="_blank">hg@hg.python.org/cpython</a>#2.7</div>
<div><br></div><div>I believe that might even strip out other history outside the \
scope of the branch.</div><meta charset="utf-8"><div> </div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex;">
<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>
</div>That's funny because to my eyes, Mercurial conflates "branches" \
and "clones".<br> Why a clone operation should give me the history for all \
lines-of-development<br> inside a working directory for one "arbitrary" one \
strikes me as bizarre<br> (pardon the pun :).</blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex;"> I get that for folks who like the "svn \
switch" method of<br> working on multiple LoDs, this probably makes a lot of \
sense. I don't<br> personally like or trust that approach much \
though.<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex;"> <div class="im"><br>
>What I'm saying is that a lot of Bazaar terminology using "branch" does<br>
>not map as-is to Mercurial. We clone a repo, we pull from a repo/clone,<br>
>we have named branches (e.g. 3.2) in a repo, we have unnamed branches on<br>
>one named branch. I think you know that already, since you went from<br>
>using Bazaar terms applied to Mercurial to mixing terms from both<br>
>("clone a new branch working directory" → "clone a repo", probably). I<br>
>salute your willingness to learn Mercurial, considering how fluent (and<br>
>fluffly) you appear to be with Bazaar.<br>
<br>
</div>This is an inevitable problem with trying to converse fluently about three<br>
major dVCSs and at least one or two other non-dVCSs. They all use the same<br>
words to mean vaguely similar things, but quickly get bogged down in the<br>
implementation details assigned to those words. It all makes perfect sense<br>
when you've been immersed in those technologies, but it makes discussions and<br>
comparisons exceedingly difficult. I've no doubt it's doubly painful to \
many<br> people who have no prior experience with a dVCS.<br>
<br>
(Aside: Bazaar could have potentially eased these folks transition because you<br>
can use Bazaar just like you would Subversion - as a centralized VCS --<br>
without stopping others from using it with full dVCS features on the same code<br>
base. I don't know if Mercurial offers the same flexibility.)<br>
<br>
It's a little like trying to teach Python to a Java programmer. \
"Object",<br> "Class", "Instance", "Import" \
all mean roughly similar things, which lulls you<br> into a false sense of \
understanding. We learn by holding up the new to the<br> light of the familiar and \
looking for interference patterns. :)<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex;"> <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>
</div>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.</blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex;"> With the<br> arrangement I outlined above (which is \
independent of the dVCS backing it), it<br> makes no sense for each LoD working \
directory to contain all the history of<br> all the other \
LoDs.<br></blockquote><div><br></div><div>As I said above, use the #<branch> \
format and you skip this issue (I think).</div><div> </div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex;">
<br>
In Bazaar, a "branch" is an independent LoD and it's \
"repository" contains<br> only its own history. Sure, it might have \
identical history with other LoDs<br> up to the point of divergence, and I have ways \
to efficiently share that<br> history across multiple LoD working directories, but \
they are still separate<br> and I don't need them if I don't care about them. \
With Mercurial, all history<br> for all LoDs in a repository always come along for \
the ride.<br> <div class="im"><br>
>You speak to my heart, sir. In your ~/.hgrc, under the section [ui],<br>
>set "editor = path/to/mercurial/source/hgeditor" and enjoy your diffs.<br>
>I use it and love it.<br>
<br>
</div>Great, I'll try that, thanks. One thing Mercurial and Bazaar definitely \
share<br> is a wealth of magical awesomeness hidden in manpages, wiki pages, \
mailing<br> list posts, people's heads, configuration files, and source code. \
:)<br> <div class="im"><br>
>If you want to commit a subset of your local changes, I use<br>
><a href="http://mercurial.selenic.com/wiki/CrecordExtension" \
target="_blank">http://mercurial.selenic.com/wiki/CrecordExtension</a> , a \
curses-based diff<br> >selection UI that works like a charm.<br>
<br>
</div>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 \
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 to<br> the master. I can shelve some or all of my uncommitted \
changes, which saves<br> them essentially out-of-the-way patch files, and then \
reverts my uncommitted<br> changes. Unshelving then is the process of re-applying \
those patch files, and<br> yes, resolving \
conflicts.<br></blockquote><div><br></div><div>Hg's is the mq (Mercurial Queue) \
extension.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
This is also a great way to work when you want to do 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 \
incrementally<br> apply them back as you write each test. I'm sure Mercurial \
has something<br> equally awesome lurking about. \
:)</blockquote><div><br></div><div><br></div><div>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). </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