Hi, 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://h...@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. > It does leave me with an empty 'master' directory that I basically won't > touch, though I suppose I could hide it in a dot-filename. Or have the master clone do double duty as the py3k clone. (IOW, I have 2.7 3.1 3.2 py3k, I pull/push in py3k and also do merges and new features in py3k). > And I have to remember to fiddle with .hg/hgrc when I clone a new branch > working directory, but I guess that's mostly a one-time cost. You don’t, see above. I’ve wanted to tell you something for a long time: Mercurial branches are not at all like Bazaar branches. See http://mercurial.selenic.com/wiki/Branch and http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/ 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>. 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. > 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.) > and eventually I'll figure out the whole merge thing. Without anything specific, I’ll point to some resources: Short tuto: http://hginit.com/04.html Concepts and examples: http://mercurial.selenic.com/wiki/Merge Longer narratives: http://hgbook.red-bean.com/read/a-tour-of-mercurial-merging-work.html http://hgbook.red-bean.com/read/managing-releases-and-branchy-development.html > One immediate thing that I'm missing from Bazaar is that 'bzr commit' invokes > my editor and always shows me a 'diff -u' in the commit message buffer. This > is incredibly handy because I don't have to remember to do the diff in a > different window, and I always have all the information I want right there to > craft the commit message. 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. 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. Kind regards, your friendly Mercurial whippersnapper _______________________________________________ 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