On 2011-02-26 22:06, Barry Warsaw wrote:
On Feb 26, 2011, at 02:05 PM, R. David Murray wrote:
On Sat, 26 Feb 2011 13:08:47 -0500, Barry Warsaw firstname.lastname@example.org wrote:
$ cd py27 # now I want to synchronize $ hg pull -u ssh://email@example.com/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?
It's different because you don't use a familiar interface to set it (i.e hg). You have to know to hack a file to make it work. That's not awesome user interface. ;)
You'd have to take this up with Mercurial's BDFL Matt. He is a strong advocate for teaching users to learn edit their .hg/hgrc files.
And he's quite firm on not wanting to have Mercurial touch .hg/hgrc -- with the single exception being to write a initial .hg/hgrc on 'hg clone', containing the default path with the location from where the repo was cloned.
Regarding Bazaar: FWIW, I periodically retried the speed of 'bzr check' - and always gave up again looking at bzr due to the horrible slowness of that command. If I have to use a DVCS I want to be able to check the integrity of my clones in reasonable time. I do it with a cron job on our internal server here and I expect it to have finished checking all our repos when I get to my desk in the morning and look into my email inbox, reading the daily email with the result of the verify runs.
After all, we do have everything secured with hashes, so we can use them, don't we?
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.
It's easy to tell what it remembers because it's exactly what you told it to remember ;). But I guess you're talking about push and pull automatically remembering the location when none was previously set. I love that feature.
And of course, bzr 'remembers' by setting a value in a config file, which of course you *could* hack if you wanted to. It's just that you don't normally have to open your editor and remember which value in which config file you have to manually modify to set the push and pull locations. I think that's a win, but YMMV. :)
Oh, and 'bzr info' always tells you what the push and pull locations are.
You can use 'hg paths' for that:
See http://selenic.com/repo/hg/help/paths or 'hg help paths' on the command line.
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 would feel better about Mercurial's if the repo where not intimately tied with a default working tree (yes, I know -U). In a sense, that's what Bazaar's shared repositories are: a place where all your history goes. In Bazaar's model though, it's not tied to a specific working tree, and it's hidden in a dot-directory.
It's still kind of beside the point - this is the way Mercurial works, and I don't really mean this thread to be an in-depth comparison between the two.
I'm quite surprised indeed to read that much about Bazaar in this thread here :)