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