On Sat, 26 Feb 2011 13:08:47 -0500, Barry Warsaw <ba...@python.org> wrote: > $ cd py27 # now I want to synchronize > $ hg pull -u ssh://h...@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
_______________________________________________ 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/archive%40mail-archive.com
