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