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