On Sat, 26 Feb 2011 13:08:47 -0500, Barry Warsaw <barry@python.org> wrote:
$ 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.
How does setting it in the hgrc differ from "remebering" it? I've never been comfortable with the bzr --remember option because I'm never sure what it is remembering. Much easier for me to see it in a config file. But, then, that's how my brain works, and other people's will work differently.
On Feb 26, 2011, at 01:49 AM, Éric Araujo wrote:
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 :). 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.
I agree with you that I don't trust the 'svn switch' style. I also find it slow. However....
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. 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.
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.
I find bazaar's model confusing, and hg's intuitive, just like Éric. And consider that I learned bazaar before mercurial. To me, it makes perfect sense that in a DVCS the "unit" is a directory containing a repository and a working copy, and that the repository is *the* repository. That is, it has everything related to the project in it, just like the master SVN repository does (plus, since it is a DVCS, whatever I've committed locally but not pushed to the master). To have a repository that only has some of the stuff in it is, IMO, confusing. I advocated for having all the Python history in one repo partly for that reason. I can intellectually see your point about not really *needing* the stuff for the LODs if you are only working on LOD X, but just like 'svn switch' makes me uncomfortable, I'm just not *comfortable* not having the whole repo in there :) As an example, with mercurial, I feel comfortable moving directories around and renaming them (with the help of google it took me about 1 minute to figure out how to keep the association between the repository instances intact). With bazaar I got in trouble trying to do that, because the interrelationship between the working copy directories (and their subsets of the repo?) and the master repo(?) was not clear. I never did figure out how to make it work, I ended up starting over with a new clone. Now, as I get farther into learning mercurial I may well find things that are just as confusing as I found that aspect of bazaar, but at least I am comfortable with the outermost layer: the repo is the repo is the repo. -- R. David Murray www.bitdance.com