
Hello, Georg and I have been working on converting the SVN repository to Mercurial. We can now present you a test repository (actually, two). CPython repository: http://hg.python.org/cpython/ ------------------ This is the main conversion repository. It contains all history of trunk and py3k (since 1990!) up to now, including all maintenance branches starting from 2.0 up to 3.2. If you are a core developer, get your local clone of the repository using: $ hg clone ssh://hg@hg.python.org/cpython (this uses the same SSH key as your Subversion access; for more information about Mercurial and SSH keys, see the converted development FAQ: http://potrou.net/hgdevguide/faq.html#faq ) If you are not a core developer: $ hg clone http://hg.python.org/cpython Your clone will contain the following branches: $ hg branches default 68026:f12ef116dd10 3.2 68025:cef92ee1a323 2.7 68010:8174d00d0797 3.1 67955:5be8b695ea86 2.6 67287:5e26a860eded 2.5 65464:e4ecac76e499 trunk 62750:800f6c92c3ed 3.0 60075:1d05144224fe 2.4 58552:df72cac1899e 2.3 45731:a3d9a9730743 2.2 40444:d55ddc8c8501 2.1 30171:06fcccf6eca8 2.0 18214:dc0dfc9565cd The branch "default" is the current py3k branch from SVN. The branch "trunk" represents SVN trunk history until 2.7 was branched for maintenance. The full list of tags is too long to print here, but you can get it using: $ hg tags The size of the repository on-disk is (depending on your filesystem): $ du -hs .hg 176M .hg (the size of the network transfer is estimated to be around 80MB) You can commit and even push to this repository (the latter if you are a core developer). Since this is a test repository, whatever you push will be discarded when we do the final conversion. CPython with extra history: http://hg.python.org/cpythonextrahist/ -------------------------- This repository is bigger, and has a much more complicated topology. It is a superset of the other repository, and contains the totality of the branches from the SVN repository (it has more than 450 repository heads, of which 87 non-closed). It also weighs quite a bit more: $ du -hs .hg 248M .hg This repository is unnecessary for development work, since even for history-digging purposes the normal repository has the necessary information. This repository is only to preserve historical record of some of the non-trunk development work from the SVN repository (such as orphaned/deleted feature branches). Development guide: http://potrou.net/hgdevguide/ ----------------- This is the development guide adapted for Mercurial. You can get its sources from the branch "hg_transition" in http://hg.python.org/devguide/. Regards Antoine.

On Thu, Feb 24, 2011 at 16:19, Antoine Pitrou <solipsis@pitrou.net> wrote:
Thanks to the both of you for moving this forward!
Just to help justify it in my head, the trunk branch exists for the history and nothing more, right? I mean we are not even accepting commits on it after we branched so I assume there is no real new history there compared to 2.7. Could we actually close the branch so it isn't even visible by default to prevent confusing people? -Brett
Just to give a comparison to svn, release-27maint is 243M and py3k is 231M (and that is with `make distclean` run). IOW the complete history of all branches of Python is just 5M bigger than just a checkout of 2.7. -Brett

On Thu, 24 Feb 2011 17:39:40 -0800 Brett Cannon <brett@python.org> wrote:
True.
Could we actually close the branch so it isn't even visible by default to prevent confusing people?
Yes, we can. This can be done post-conversion, actually. Something like: $ hg up trunk $ hg ci --close-branch -m "Close trunk" Regards Antoine.

On 25.02.2011 01:19, Antoine Pitrou wrote:
The implied agenda is that we would be *very* happy if we could do the final conversion during PyCon (we both won't be attending, so we have plenty of time ;) -- so that the sprints can already benefit from the agility provided by hg. That's a timescale of around two weeks, which should be plenty for testing.
[...]
So, to stress this point: Please *do* experiment, commit and push stuff to this repository, especially if you've not worked with hg before. You can break nothing (or if you do, it's not your fault :) Georg

On Fri, Feb 25, 2011 at 01:19, Antoine Pitrou <solipsis@pitrou.net> wrote:
Georg and I have been working on converting the SVN repository to Mercurial. We can now present you a test repository (actually, two).
Sorry everyone for taking so long on the conversion. Looks like Antoine and Georg have more time and energy to spend on this than I do, so I will let them pick up my slack. Cheers, Dirkjan

Georg and I have been working on converting the SVN repository to Mercurial. We can now present you a test repository (actually, two).
Thanks for working on this! How do you want bugs reported? Can you please update the PEP? I see at least the following deviations: - the extrahist repository is not mentioned - the branchmap is (apparently?) not evaluated; in particular, it's not clear whether the keep-clone branches went. - it's not clear what your view on the subversion repository is - do you keep the notion of discarded branches (i.e. branches that can only be discovered from looking at a copy of the subversion repository), or do you mean to convert everything? As for the cpythonextrahist repository: why are the heads all unnamed? How are you supposed to find anything in it? I think I would have liked the strategy of the PEP better (i.e. create clones for feature branches, rather than putting all in a single repository). Regards, Martin

On Fri, Feb 25, 2011 at 09:25, "Martin v. Löwis" <martin@v.loewis.de> wrote:
If there are hundreds of them, it's far from trivial. I don't even know how to find out which one to convert.
Right, I mostly mean it's trivial for Antoine or Georg to extract into a clone (at least that's how I was planning to do it, not sure what their idea is). Cheers, Dirkjan

On 25.02.2011 09:25, "Martin v. Löwis" wrote:
The full-history repo has several ways to get at that information, so it's quite for us to extract feature branches as separate clones. Since most side-track branches won't actually be needed anymore, we'd like to reconstruct them on request. I assume you'd like to have pep-0383? Georg

On Feb 25, 2011, at 01:50 AM, Raymond Hettinger wrote:
The way I work with the Subversion branches is to have all the active branches checked out into separate directories under a common parent, e.g. ~/projects/python/py26 ~/projects/python/py27 ~/projects/python/trunk ~/projects/python/py31 ~/projects/python/py32 ~/projects/python/py3k This makes it very easy to just cd, svn up, make distclean, configure, make to test things. How can I do this with the hg clone when all the branches are in the single repository, but more or less hidden? After doing the 'hg clone' operation specified by Antoine, I'm left with a single cpython directory containing (iiuc) the contents of the 'default' branch. I'm sure I'm not the only one who works this way with Subversion. IWBN to cover this in the devguide (or is it there and I missed it?). Cheers, -Barry

Hi Barry,
Indeed, the default branch is checked out by default. But you can switch to another branch: $ hg sum parent: 68026:f12ef116dd10 tip In FTP.close() method, make sure to also close the socket object, not only the file. branch: default commit: (clean) update: (current) $ hg up 2.7 3310 files updated, 0 files merged, 378 files removed, 0 files unresolved $ hg sum parent: 68010:8174d00d0797 Merged revisions 88486 via svnmerge from branch: 2.7 commit: (clean) update: (current) ("hg sum" is a shorthand for "hg summary") Furthermore, once you have a local clone, you can clone it further to get several independent clones, and keep each of them updated on whatever branch you want. This makes it easy to replicate your workflow (by having a "master clone" - a mirror if you want - and then child clones that get updated from the master clone by running "hg pull").
I'm sure I'm not the only one who works this way with Subversion. IWBN to cover this in the devguide (or is it there and I missed it?).
Use of "hg update" to switch between branches is mentioned in http://potrou.net/hgdevguide/setup.html#getting-the-source-code and also http://potrou.net/hgdevguide/coredev.html#read-write-checkout and also in http://potrou.net/hgdevguide/committing.html#porting-within-a-major-version. But a dedicated FAQ entry could be added. Regards Antoine.

On 25.02.2011 17:12, Barry Warsaw wrote:
Two scenarios are possible: * You make a clone per branch with the full history, with the current branch being different in each of those. Since "hg update" updates to the head of the current branch, this should be easy to do. When you pull from the single repo you will get changes for the other branches as well, but they will not bother you. * You make a clone per branch, containing *only* the respective branch (with its ancestors). This is done by using "URI#branchname" as the source when cloning/pulling. Both should work equally well, with the former giving larger repository sizes, and the latter taking somewhat longer on the initial clone. Georg

On 2011-02-25 17:12, Barry Warsaw wrote:
I know (almost) nothing about developing Python (this is my first post to this list after lurking for quite a while now), but as a regular Mercurial contributor, I think the following could be useful for you: First, get an initial clone (let's name it 'master') over the wire using: [1] $ hg clone -U ssh://hg@hg.python.org/cpython master Then create a hardlinked clone [2] for working in each branch, specifying the branch to check out using option -u: $ hg clone master py26 -u 2.6 updating to branch 2.6 NNN files updated, 0 files merged, 0 files removed, 0 files unresolved $ hg clone master py27 -u 2.7 updating to branch 2.7 NNN files updated, 0 files merged, 0 files removed, 0 files unresolved $ hg clone master trunk -u trunk updating to branch trunk NNN files updated, 0 files merged, 0 files removed, 0 files unresolved $ hg clone master py31 -u 3.1 updating to branch 3.1 NNN files updated, 0 files merged, 0 files removed, 0 files unresolved $ hg clone master py32 -u 3.2 updating to branch 3.2 NNN files updated, 0 files merged, 0 files removed, 0 files unresolved This will be fast and save space as these local 'branch clones' will share diskspace inside .hg/store by using hardlinks, and you need to do the initial slow clone over the wire only once. 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://hg@hg.python.org/cpython instead, you'd want to edit the [paths] section in the .hg/hgrc file in each of the branch repos. But of course you can also leave the default paths as they are and synchronize via the master repo (e.g. pull new changesets into master first, and then pull into the specific branch repo). [1] http://selenic.com/repo/hg/help/clone [2] http://mercurial.selenic.com/wiki/HardlinkedClones [3] http://www.selenic.com/mercurial/hgrc.5.html#paths [4] http://selenic.com/repo/hg/help/urls

On Feb 25, 2011, at 06:40 PM, Adrian Buehlmann wrote:
Thanks very much Adrian, this is exactly what I was looking for. It maps almost directly to my current mental model for working on Python in Subversion (and truth be told, also how I do/did it with Bazaar). 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. 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. I'll have to remember that 'hg pull' does not update the working copy by default, and eventually I'll figure out the whole merge thing. 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. It doesn't look like this is possible with 'hg commit' though, right? Cheers, -Barry

On Fri, 25 Feb 2011 14:43:15 -0500 Barry Warsaw <barry@python.org> wrote:
I'll have to remember that 'hg pull' does not update the working copy by default, and eventually I'll figure out the whole merge thing.
You can use "hg pull -u" to update (and "hg pull -uv" if you want to see the list of updated files).
Should be customizable: http://mercurial.selenic.com/wiki/CommitMessageTemplate http://mercurial.selenic.com/wiki/DiffsInCommitMessageInVIM (never tried myself) Regards Antoine.

On 25/02/2011 20:43, Barry Warsaw wrote:
What you are asking for is available in TortoiseHg which absolutely rocks (if you are not allergic to the idea of a graphical tool). You can even select indvidually inside a file which lines to commit or not. A bit risky but very handy when you have a few oneliners to commit or not to commit. cheers, Philippe

On Feb 25, 2011, at 09:04 PM, Philippe Fremy wrote:
What you are asking for is available in TortoiseHg which absolutely rocks (if you are not allergic to the idea of a graphical tool).
Like shellfish, bee-strings, and Perl I'm afraid. :)
You mean, TortoiseHg supports incremental commits on a single file? That's kind of neat, but scary. ;) -Barry

Barry Warsaw writes:
You mean, TortoiseHg supports incremental commits on a single file? That's kind of neat, but scary. ;)
Darcs people have been doing this for, well, for as long as Darcs has existed. It's not scary at all. In fact, in Darcs you can select hunks across files, too.

On 25Feb2011 14:43, Barry Warsaw <barry@python.org> wrote: | [...] 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. Hmm. Why do you need to fiddle with the hgrc? Just curious. | I'll have to remember that 'hg pull' does not update the working copy by | default, and eventually I'll figure out the whole merge thing. "hg fetch" does though. That's my usual incanation. | 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. It doesn't look like this is possible with 'hg | commit' though, right? CVS had that problem. I had a wrapper somewhere that masquerades as $EDITOR and writes a diff into the commit buffer as you describe. [ Digs through my hg repository... ] Ok; then it took the form of a script called "cvscommit" that set $EDITOR to the command "cvscommit-editor", wrote the diff stuff, invoked "cvs commit". That ran "cvscommit-editor", which invoked the old $EDITOR and off you went. I would think editing the hgrc to set the hg editor and using the commit hooks would streamline this for Mercurial so you could do the usual "hg commit" command without going through the outer wrapper. I'll devote a little time today, since I've missed this little hack:-( Interested? Cheers, -- Cameron Simpson <cs@zip.com.au> DoD#743 http://www.cskk.ezoshosting.com/cs/ We don't just *borrow* words; on occasion, English has pursued other languages down alleyways to beat them unconscious and rifle their pockets for new vocabulary. - James D. Nicoli

Hi, Le 25/02/2011 20:43, Barry Warsaw a écrit :
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.ht...
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

On Feb 26, 2011, at 01:49 AM, Éric Araujo wrote:
So let's start from the basics. I want separate working directories for each active line-of-development (I'll use that term instead of "branch"), e.g. working directories containing the tip of the 2.6 LoD, 2.7, 3.1, 3.2, and 3.3. I will not be doing feature or bug development in any of these directories. They are purely for local tracking of the remote masters. Thus, I want to be able to synchronize any one of those LoDs against the remote master with one command, like I would using Subversion's 'svn up'. 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 (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.) 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.
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.
This is an inevitable problem with trying to converse fluently about three major dVCSs and at least one or two other non-dVCSs. They all use the same words to mean vaguely similar things, but quickly get bogged down in the implementation details assigned to those words. It all makes perfect sense when you've been immersed in those technologies, but it makes discussions and comparisons exceedingly difficult. I've no doubt it's doubly painful to many people who have no prior experience with a dVCS. (Aside: Bazaar could have potentially eased these folks transition because you can use Bazaar just like you would Subversion - as a centralized VCS -- without stopping others from using it with full dVCS features on the same code base. I don't know if Mercurial offers the same flexibility.) It's a little like trying to teach Python to a Java programmer. "Object", "Class", "Instance", "Import" all mean roughly similar things, which lulls you into a false sense of understanding. We learn by holding up the new to the light of the familiar and looking for interference patterns. :)
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.
Great, I'll try that, thanks. One thing Mercurial and Bazaar definitely share is a wealth of magical awesomeness hidden in manpages, wiki pages, mailing list posts, people's heads, configuration files, and source code. :)
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. 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. :) -Barry

On Sat, 26 Feb 2011 13:08:47 -0500, Barry Warsaw <barry@python.org> wrote:
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.
I agree with you that I don't trust the 'svn switch' style. I also find it slow. However....
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

On Feb 26, 2011, at 02:05 PM, R. David Murray wrote:
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. ;)
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.
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. -Barry

On Sat, 26 Feb 2011 16:06:45 -0500 Barry Warsaw <barry@python.org> wrote:
Often (but not always), when you're wanting to do something, there's an extension for Mercurial which can be enabled ;) http://mercurial.selenic.com/wiki/ShareExtension Regards Antoine.

On 2011-02-26 22:06, Barry Warsaw wrote:
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?
You can use 'hg paths' for that: See http://selenic.com/repo/hg/help/paths or 'hg help paths' on the command line.
I'm quite surprised indeed to read that much about Bazaar in this thread here :)

On Feb 26, 2011, at 11:45 PM, Adrian Buehlmann wrote:
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.
Well, I guess it's doubtful I'd change his mind then. :)
Do you know how thorough 'bzr check' is? I don't, but then I've never used it or felt the need to. ;)
Oh, and 'bzr info' always tells you what the push and pull locations are.
You can use 'hg paths' for that:
Nice, thanks. -Barry

On 2011-02-27 01:50, Barry Warsaw wrote:
Yep.
That's quite amazing. If I talk with people about that, it often turns out that they don't check the integrity of their repos. Well, hg verify *is* through and fast enough. That's good enough for me. And being slow is not sufficient to earn my trust. FWIW, be aware that Mercurial does not do integrity checks on normal operations, so chances are you will be able to use a repo that fails verify for quite a while -- without even noticing it. For example you can remove *some* file X inside .hg/store/data and continue to add history to that repo without any sign of errors, as long as the file X isn't used during the operations you do.

On Sat, Feb 26, 2011 at 10:08, Barry Warsaw <barry@python.org> wrote:
For other people's benefit, LoD == line of development (I think).
That's one way of doing it.
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.
So does Hg: simply edit your .hgrc to have it both pull and push to the same URL. 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.
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.
Neither do I in an svn context and why Hg does let you check out just a branch and have all pulls and pushes only go to that branch.
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.
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.
As I said above, use the #<branch> format and you skip this issue (I think).
Hg's is the mq (Mercurial Queue) extension.
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).

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'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.
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.
Right, see my follow up to RDM.
That might be a better way if it doesn't slurp down the entire repository history.
Yep, I get all that. It's Mercurial's model of the world.
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. :)
No really, I do get all that! I just don't like it much. Maybe it'll grow on me though.
I think mq is more like quilt than shelve. The moral equivalents in Bazaar would probably be the loom and pipeline extensions.
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

On Sat, Feb 26, 2011 at 1:37 PM, Brett Cannon <brett@python.org> wrote:
There is hg-git, but that is hg on top of git.
Actually, hg-git is bidirectional. The hg-git documentation is written from the perspective of an hg client talking to a git server, but for a DVCS "client" and "server" are a matter of perspective. I spent some time on Friday setting up hg-git on my workstation and making a few test commits. It took me awhile to figure out how to get everything working, but it seems to work smoothly now. At some point I'll update http://wiki.python.org/moin/Git with instructions. -- Daniel Stutzbach

On Sat, Feb 26, 2011 at 3:09 PM, Brett Cannon <brett@python.org> wrote:
Hg's is the mq (Mercurial Queue) extension.
I prefer the hg shelve plugin (http://mercurial.selenic.com/wiki/ShelveExtension) for this, more intuitive to me

On Feb 26, 2011, at 01:49 AM, Éric Araujo wrote:
Except it doesn't quite work the way I want it to (hg 1.6.3). It opens your editor with two files, one is the commit message and the other is the diff. (The script itself is a bit buggy too. ;) But it's a good clue, and I've modified the default hgeditor script to get closer, and fix the bug I noticed. I basically append the diff to the temporary log message file. It's still not right though because if the diff lines aren't prepended with 'HG:', they end up in the commit message. Arg. Oh well, I can clearly hack a more complicated script together. It's such a blindingly obvious improvement, it's too bad 'hg commit' doesn't DTRT by default. -Barry

On 26.02.2011 21:49, Barry Warsaw wrote:
While I understand the usefulness of the diff feature, it is not useful to everyone, e.g. those using almost exclusively ``commit -m message``. Of course it would be nice if hg made it easier (a hgrc option, for example) to do this. BTW, I had not heard of hgeditor before, and wrote a small hg extension to do what you want (with HG: prefix :) before I saw that others had already replied with hgeditor. The extension had 10 lines of code. Georg

On Feb 27, 2011, at 05:38 PM, Georg Brandl wrote:
While I understand the usefulness of the diff feature, it is not useful to everyone, e.g. those using almost exclusively ``commit -m message``.
The editor window doesn't pop up when you provide the -m flag, so the diff output is not relevant.
Of course it would be nice if hg made it easier (a hgrc option, for example) to do this.
Sure.
We should find a place (i.e. repository) to stash these useful add-ons and hacks so that all Python developers can find them. -Barry

On Mon, 28 Feb 2011 10:08:26 -0500 Barry Warsaw <barry@python.org> wrote:
I think you can simply add them somewhere on the hg wiki: http://mercurial.selenic.com/wiki/ and then link to the pages from our own wiki, or the developer's FAQ. Regards Antoine.

Hi, As a mercurial user, I thank you for this effort! One question, where/how do I send suggestion to what to add into .hgignore file? In particular, I found these dynamically generated files after a build in Windows (3.2) that probably should be entered as .hgignore entries: ? PC/python_nt_d.h ? PC/pythonnt_rc_d.h ~/santa On Mon, Feb 28, 2011 at 1:10 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:

[...] publishing patches by referring to a remote repository,
rather than uploading the diff.
Is this a recommended workflow at this point, or should we generate/attach patch files still? Both, for experimentation? ~/santa On Fri, Mar 4, 2011 at 1:15 PM, "Martin v. Löwis" <martin@v.loewis.de>wrote:

Le vendredi 04 mars 2011 à 14:03 -0800, Santoso Wijaya a écrit :
Pragmatically, I think we would still prefer patches, but Mercurial should make it much easier to maintain them - e.g. you can use mq (which is what Mercurial devs themselves use, actually). We can also experiment with other forms of publishing changes, but I think that would require the publisher to somehow collapses their own changesets, so that it finally amounts to reviewing a patch. In my opinion at least, it would be bad if we started integrating intermediate changesets leading to a final patch just because Mercurial allows us to do it. I think it's better if the public history line doesn't get obscured with work-in-progress changesets. Regards Antoine.

On Fri, 04 Mar 2011 13:01:02 -0800, Santoso Wijaya <santoso.wijaya@gmail.com> wrote:
I, on the other hand, would like to see .rej and .orig removed from the ignore list. I don't like having these polluting my working directory, and 'hg status' is the easiest way to find them (if they aren't ignored). Or if there's some way to configure my personal .hgrc to ignore those particular ignore lines, that would be fine too :) -- R. David Murray www.bitdance.com

On 6 March 2011 00:44, R. David Murray <rdmurray@bitdance.com> wrote:
If those were to be removed from .hgignore then there would be a high likelihood of someone doing "hg addremove" and inadvertently tracking them. The purpose of .hgignore is to prevent inadventently tracking files that shouldn't be tracked. "hg status -i" will list all ignored files that are present in your working directory. For other options, "hg help status". Tim Delaney

On Sun, 06 Mar 2011 00:54:39 +1100, Tim Delaney <timothy.c.delaney@gmail.com> wrote:
Ah, well, I don't like that UI. The purpose for me of .hgignore (and similar ignore files) is to make the status command show any files that have been modified or aren't normal build/run products. I'd rather add and remove files individually by hand (except when adding or removing a directory). I also want a --strict option for the commit command that refuses to commit if there are unignored unadded or missing files. (--strict is the bzr spelling; I don't care about the spelling :)
"hg status -i" will list all ignored files that are present in your working directory. For other options, "hg help status".
hg status -i is useless because there are a *lot* of ignored files in a working directory where python has been built. I'd have to do a distclean first, which would mean I'd have to do a rebuild after...and all of that just takes too long :) I guess I have some hg hacking in my future, unless someone has already written extensions for this stuff. -- R. David Murray www.bitdance.com

On Sat, 5 Mar 2011 08:36:04 -0800 Daniel Stutzbach <stutzbach@google.com> wrote:
Well, it's more user-friendly to help "hg addremove" work as expected, rather than add hooks down the line to forbid pushing any mistakes. Regards Antoine.

With hg 1.7.5 on Windows 7 I performed a non-core checkout: hg clone http://hg.python.org/cpython The eol extension is enabled in global settings. I looked at things a bit, opening some files and using the Tortoise Hg Repository Explorer. But made no actual changes. Running hg diff produces a large amount of output with almost all the *.decTest and most of the Windows build files (*.mk, *.sln, *.vcproj, *.bat) showing as changed but with identical text. I've had problems like this with Hg before (http://mercurial.selenic.com/bts/issue2287). The situation can be fixed by hg update to another version and then back to default. Neil

On Fri, 25 Feb 2011 19:13:49 +1100 Neil Hodgson <nyamatongwe@gmail.com> wrote:
Yes, please try to disable it. The issue is we have a .hgeol in the repository right now (it's in the SVN repository too), but it doesn't match the reality of on-disk files, so when you update, the eol extension tries to "fix" those files. Regards Antoine.

On Fri, 25 Feb 2011 13:52:58 +0100 Antoine Pitrou <solipsis@pitrou.net> wrote:
It should now be fixed in current SVN, meaning the final conversion should be perfectly usable with the eol extension enabled. Do you find other issues under Windows? Have you tried pushing changes? Regards Antoine.

Antoine Pitrou:
It should now be fixed in current SVN, meaning the final conversion should be perfectly usable with the eol extension enabled.
Good.
Do you find other issues under Windows? Have you tried pushing changes?
Since I'm not a member of core developers I used a http pull and can't push: C:\u\cpython>hg push pushing to http://hg.python.org/cpython searching for changes remote: ssl required Neil

On Fri, Feb 25, 2011 at 10:19 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Would it be possible to name "trunk" as "2.x" instead? Otherwise I could see people getting confused and asking why trunk was closed, and/or not the same as "default". Looking very nice, though! :) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On Sat, 26 Feb 2011 12:32:04 +1000 Nick Coghlan <ncoghlan@gmail.com> wrote:
That was my first idea, but then I realized that the branch includes 1.x and even pre-1.0 commits, so "2.x" might actually be more confusing/misleading and hide the fact that the full trunk history is there. I think people should simply get used to the idea that "default" is /the/ main branch in Mercurial (*). It's even easier to remember IMHO ("trunk" sounds a bit obscure at first, for a non-native English speaker). (*) but it's not any special really, it's just the branch you get by... default ;) Regards Antoine.

On 26/02/2011 14:44, Antoine Pitrou wrote:
Well, except for the prevalence of "trunk" as terminology to mean "place where current development happens". It will lead to odd conversations like: "is trunk the trunk?", "no trunk is what used to be trunk, default is now trunk". Renaming it "legacy-trunk" is no less precise, but more explicative. Michael
-- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html

Although I now admit "legacy-trunk" sounds quite accurate, and conveys a clear warning to anyone wondering if they should use it.
To stay in tree terminology, I propose "stump" (*). Or "rotten-trunk". Bikeshedding is such a fun activity :-) Regards, Martin (*) m-w.com: "the part of a plant and especially a tree remaining attached to the root after the trunk is cut"

On Sat, 26 Feb 2011 17:49:32 +0100 Éric Araujo <merwok@netwok.org> wrote:
IMO, a dummy merge at the tip of the default branch may confuse users looking at the history, especially if they try a graphical display of the DAG (e.g. "hg glog" or the graph page in the Web UI). Besides, it would precisely make it harder to distinguish between trunk and py3k development at the time both took place in parallel. Regards Antoine.

On Sun, Feb 27, 2011 at 3:00 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Besides, it would precisely make it harder to distinguish between trunk and py3k development at the time both took place in parallel.
With the legacy branches now being closed so they don't appear in the default output from hg commands, I'm fine with keeping the old "trunk" name from SVN. It was only when those commands were displaying both "trunk" and "default" that it bothered me. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

The dummy merge would not stay long: The commits targeted at 3.3 would be its children.
Besides, it would precisely make it harder to distinguish between trunk and py3k development at the time both took place in parallel.
IIUC, there would be two parallel lines of history (unnnamed branches). Would that be hard to read? Regards

On Sat, Feb 26, 2011 at 8:44 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Maybe I don't fully understand how Mercurial branches work or how it defines terminology (in fact, that is likely :) ). What's the difference between the statement "trunk changesets are strict ancestors of 2.7" and the statement "trunk's history is a strict subset of 2.7's history"? -- Daniel Stutzbach

Named branches are exclusive, they can't be a subset of each other ;)
Actually, they can. Take the example of the Mercurial repo itself. They fix bugs in the stable branch and add features in default. When they merge stable into default and commit, default becomes a superset of stable. That is to say, someone pulling default also gets the changesets from stable that are ancestors of the merge changset. Or in other words, if you check out default, you get all bug fixes from stable. HTH

A Mercurial 'merge' <http://mercurial.selenic.com/wiki/Branch> is simply a creation of another changeset, which has two parents: the current tip of the branch you're working on, and the changeset you are merging with. ~/santa On Sat, Feb 26, 2011 at 10:23 AM, Barry Warsaw <barry@python.org> wrote:

Le samedi 26 février 2011 à 09:27 -0800, Daniel Stutzbach a écrit :
Apparently you overlooked the first statement: "Named branches are exclusive". In other words, a changeset can be in only one named branch. So it's impossible for a branch to be a subset or superset of another. (except the trivial case of an empty branch :-)).

Am 26.02.2011 17:44, schrieb Antoine Pitrou:
But is there a need to have any changesets in the "trunk" named branch? Couldn't the historical changesets just be in an unnamed branch, being ancestor of so many named branches? I'd like to prevent people from mistakenly committing onto the trunk, which would be easiest if trunk didn't exist at all. Regards, Martin

Le samedi 26 février 2011 à 18:36 +0100, "Martin v. Löwis" a écrit :
There is no such thing as an "unnamed branch". What would "hg branches" show? An empty space?
I'd like to prevent people from mistakenly committing onto the trunk, which would be easiest if trunk didn't exist at all.
Well, the push you request in the todo should do the trick. We can also call it "legacy-trunk", too :) Regards Antoine.

hg branches doesn't list unnamed branches. "hg heads" omits any branch name for unnamed branches. See the cpythonextras repository for examples: changeset: 72694:e65daae6cf44 user: Antoine Pitrou <solipsis@pitrou.net> date: Mon Feb 21 21:30:55 2011 +0000 summary: Try s/UINT_MAX/INT_MAX/ This is listed as a head, but not of a named branch.
Yes, that would also work. However, when then somebody proposed that we may not need the trunk branch at all in the conversion result (which I still think is the case - we don't need it), I noticed that this would solve the problem in a more clean manner.
We can also call it "legacy-trunk", too :)
I think we can do better. I also dislike "hg log --only-branch default" to only go back to 2006 (to aeefba456e4d), when this revision actually does have a parent (namely, on the trunk branch, 4b41806a0326). So I would propose this attribution to branches: - everything that is ancestor of the default branch is attributed to the default branch, back to the very beginning of the repository. - Everything currently on trunk that wouldn't be on default is then attributed to the oldest branch that it is an ancestor of, in the order 2.0, 2.1, 2.2, ... 2.7. So e.g. the 2.7 branch would go back to where it branched from the 2.6 branch (after the actual creation of the 2.6 branch in svn), which would go back to where it branched from 2.5, and so on. Regards, Martin

It's not on an unnamed branch, it's on the "default" branch (which is omitted for concision by "hg log" and other commands with a similar output).
But you *need* the changesets from the trunk branch. You are just arguing for giving them another label (including "" or "default"), hence:
I'm not convinced that small quirks of using "hg log" are important at this point. Also, you could try other options of "hg log" such as "--follow". If we called ex-trunk the same name as ex-py3k ("default"), things would probably be quite more confusing, since inspecting a changeset wouldn't tell you immediately where it comes from (2.x or 3.x development). Regards Antoine.

It's probably a terminology issue, but: the changeset can't be "on" the default "branch", because the head of the default branch (called "tip", IIUC) isn't a descendant of that changeset. It's parent is changeset: 72693:d9769c8a828b user: Antoine Pitrou <solipsis@pitrou.net> date: Mon Feb 21 21:25:39 2011 +0000 summary: temp branch to debug crashes on snow leopard buildbot so you have called it "temporary branch" in subversion. I got go with that term also, if "unnamed branch" is confusing.
IIUC, --follow doesn't help. It traces history across renames and copies, which is not what I want to overcome when trying to produce the full history of the py3k branch. As for "small quirks ... important at this point": this point is the *only* chance to get it right. If you get it wrong now, we will have to deal with it forever (or rather until we switch to the next version control system). If you chose to convert in the way it currently does: fine with me, as long as the choice was deliberate (rather than coincidental).
I would it call default only up to the point where the py3k branch was branched off trunk. All changes up to this point actually *do* belong to both branches. Python 3's history goes all the way back to 0.9, and I'm sure you can still find code in 3.2 which was written 20 years ago. Change sets created after 3.x was forked off should certainly live on a separate mercurial branch - it would be reasonable to call this branch then 2.x. Regards, Martin

On Sun, 27 Feb 2011 08:09:21 +0100 "Martin v. Löwis" <martin@v.loewis.de> wrote:
Well, a branch (or named branch) in hg terminology can have several heads (see the other email about heads and branches). Also, just so you know, "tip" is simply the latest (in pull or commit order) changeset in the local repository. It can be in any branch (for example, if you pull of bunch of changesets someone made in "3.2", then your tip will be in branch "3.2"). I hope it all starts to make sense ;) Regards Antoine.

On Sat, Feb 26, 2011 at 9:55 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
There is no such thing as an "unnamed branch". What would "hg branches" show? An empty space?
I understand now why I was confused. I had previously read the sentence "Both Git and Mercurial support unnamed local branches." at http://mercurial.selenic.com/wiki/BranchingExplained But as I dig deeper, I see that there is only one unnamed branch, and it actually does have an implicit name: "default". It appears Mercurial supports at least three different kinds of branching: cloning (similar to Bazaar), bookmarks (similar to git), and named branches. So a named branch can contain more than one branch. Were there reasons for going with named branches over bookmarks? PEP 385 discusses only cloning and named branches. I'm just curious, not trying to start a long discussion. :-) -- Daniel Stutzbach

From http://mercurial.selenic.com/wiki/Branch#Named_branches:
[...] a good rule of thumb is to use branch names sparingly and for rather longer lived concepts like "release branches" (rel-1, rel-2, etc) and rather not for short lived work of single developers So I think named branches make sense here. Bookmarks are really for potential branches, experimental features, for example, for easier navigation for the developer's convenience. Named branches, on the other hand, are better for posterity reasons. ~/santa On Sat, Feb 26, 2011 at 10:40 AM, Daniel Stutzbach <stutzbach@google.com>wrote:

On Sat, 26 Feb 2011 10:40:03 -0800 Daniel Stutzbach <stutzbach@google.com> wrote:
Ok, so beware, the term "branch" can conflate two concepts: - a path in the topology (or line of development) - a "named branch" in hg terminology So, actually, hg promotes a slightly different terminology: - a "head" is a changeset without a child in the topology - a "branch" usually means a "named branch": a set of changesets bearing the same label (e.g. "default"); that label is freely chosen by the committer at any point, and enforces no topological characteristic (even though in practice it will have, since it's the whole point from the user's perspective, and also because hg's default behaviour and concept of a "current branch" encourages it) A (named) branch can have zero, one, or several heads: - zero head: if all branch-local heads have a child in another named branch (for example, "trunk" is linearly followed by "2.7") - several heads: if several lines of development were started in this branch without bothering to give them separate names When you have several heads on a branch, you can merge them together if you want to reconcile the lines of development they represent. When you have several branches with at least one head each, you can also merge them together: you must be careful to choose which named branch the merge changeset will be part of (for example, if you want to merge "3.1" into "3.2", you will certainly want the merge changeset to be part of "3.2", otherwise "3.1" will get a lot of unwanted features ;-)). Note: a branch with zero head is marked "inactive" in "hg branches". This basically means that it has already been merged in another branch. (of course, you can still develop in that branch, which will certainly create a new head as soon as you commit your first new changeset) Regards Antoine.

From: Antoine Pitrou
There are *some* topological restrictions, because hg won't let you assign a branch name that's been used before to a node unless one of its parents has that name. So you can't create two disconnected subgraphs whose nodes have the same branch name. -- Greg This email may be confidential and subject to legal privilege, it may not reflect the views of the University of Canterbury, and it is not guaranteed to be virus free. If you are not an intended recipient, please notify the sender immediately and erase all copies of the message and any attachments. Please refer to http://www.canterbury.ac.nz/emaildisclaimer for more information.

On 2011-02-26 23:26, Greg Ewing wrote:
That's not completely correct. You *can* do that. Mercurial by default assumes you're probably in error if you are trying to create such disconnected branch name subgraphs, but you can convince it that it's really what you want by doing: hg branch --force <existing branch name> Example (glog command requires the graphlog extension enabled [1]): $ hg init a $ cd a $ echo foo > bla $ hg ci -Am1 adding bla $ hg branch b1 marked working directory as branch b1 $ hg ci -m2 $ hg branch default abort: a branch of the same name already exists (use 'hg update' to switch to it) $ hg branch --force default marked working directory as branch default $ hg ci -m3 created new head $ hg glog --template "{rev}, {branch}\n" @ 2, default | o 1, b1 | o 0, default [1] http://mercurial.selenic.com/wiki/GraphlogExtension

So, actually, hg promotes a slightly different terminology: - a "head" is a changeset without a child in the topology
So what do you call the LoD leading up to a head? (i.e. the set of changesets that are ancestors of a head and not ancestors of any other head) Regards, Martin

On Thu, Feb 24, 2011 at 16:19, Antoine Pitrou <solipsis@pitrou.net> wrote:
Thanks to the both of you for moving this forward!
Just to help justify it in my head, the trunk branch exists for the history and nothing more, right? I mean we are not even accepting commits on it after we branched so I assume there is no real new history there compared to 2.7. Could we actually close the branch so it isn't even visible by default to prevent confusing people? -Brett
Just to give a comparison to svn, release-27maint is 243M and py3k is 231M (and that is with `make distclean` run). IOW the complete history of all branches of Python is just 5M bigger than just a checkout of 2.7. -Brett

On Thu, 24 Feb 2011 17:39:40 -0800 Brett Cannon <brett@python.org> wrote:
True.
Could we actually close the branch so it isn't even visible by default to prevent confusing people?
Yes, we can. This can be done post-conversion, actually. Something like: $ hg up trunk $ hg ci --close-branch -m "Close trunk" Regards Antoine.

On 25.02.2011 01:19, Antoine Pitrou wrote:
The implied agenda is that we would be *very* happy if we could do the final conversion during PyCon (we both won't be attending, so we have plenty of time ;) -- so that the sprints can already benefit from the agility provided by hg. That's a timescale of around two weeks, which should be plenty for testing.
[...]
So, to stress this point: Please *do* experiment, commit and push stuff to this repository, especially if you've not worked with hg before. You can break nothing (or if you do, it's not your fault :) Georg

On Fri, Feb 25, 2011 at 01:19, Antoine Pitrou <solipsis@pitrou.net> wrote:
Georg and I have been working on converting the SVN repository to Mercurial. We can now present you a test repository (actually, two).
Sorry everyone for taking so long on the conversion. Looks like Antoine and Georg have more time and energy to spend on this than I do, so I will let them pick up my slack. Cheers, Dirkjan

Georg and I have been working on converting the SVN repository to Mercurial. We can now present you a test repository (actually, two).
Thanks for working on this! How do you want bugs reported? Can you please update the PEP? I see at least the following deviations: - the extrahist repository is not mentioned - the branchmap is (apparently?) not evaluated; in particular, it's not clear whether the keep-clone branches went. - it's not clear what your view on the subversion repository is - do you keep the notion of discarded branches (i.e. branches that can only be discovered from looking at a copy of the subversion repository), or do you mean to convert everything? As for the cpythonextrahist repository: why are the heads all unnamed? How are you supposed to find anything in it? I think I would have liked the strategy of the PEP better (i.e. create clones for feature branches, rather than putting all in a single repository). Regards, Martin

On Fri, Feb 25, 2011 at 09:25, "Martin v. Löwis" <martin@v.loewis.de> wrote:
If there are hundreds of them, it's far from trivial. I don't even know how to find out which one to convert.
Right, I mostly mean it's trivial for Antoine or Georg to extract into a clone (at least that's how I was planning to do it, not sure what their idea is). Cheers, Dirkjan

On 25.02.2011 09:25, "Martin v. Löwis" wrote:
The full-history repo has several ways to get at that information, so it's quite for us to extract feature branches as separate clones. Since most side-track branches won't actually be needed anymore, we'd like to reconstruct them on request. I assume you'd like to have pep-0383? Georg

On Feb 25, 2011, at 01:50 AM, Raymond Hettinger wrote:
The way I work with the Subversion branches is to have all the active branches checked out into separate directories under a common parent, e.g. ~/projects/python/py26 ~/projects/python/py27 ~/projects/python/trunk ~/projects/python/py31 ~/projects/python/py32 ~/projects/python/py3k This makes it very easy to just cd, svn up, make distclean, configure, make to test things. How can I do this with the hg clone when all the branches are in the single repository, but more or less hidden? After doing the 'hg clone' operation specified by Antoine, I'm left with a single cpython directory containing (iiuc) the contents of the 'default' branch. I'm sure I'm not the only one who works this way with Subversion. IWBN to cover this in the devguide (or is it there and I missed it?). Cheers, -Barry

Hi Barry,
Indeed, the default branch is checked out by default. But you can switch to another branch: $ hg sum parent: 68026:f12ef116dd10 tip In FTP.close() method, make sure to also close the socket object, not only the file. branch: default commit: (clean) update: (current) $ hg up 2.7 3310 files updated, 0 files merged, 378 files removed, 0 files unresolved $ hg sum parent: 68010:8174d00d0797 Merged revisions 88486 via svnmerge from branch: 2.7 commit: (clean) update: (current) ("hg sum" is a shorthand for "hg summary") Furthermore, once you have a local clone, you can clone it further to get several independent clones, and keep each of them updated on whatever branch you want. This makes it easy to replicate your workflow (by having a "master clone" - a mirror if you want - and then child clones that get updated from the master clone by running "hg pull").
I'm sure I'm not the only one who works this way with Subversion. IWBN to cover this in the devguide (or is it there and I missed it?).
Use of "hg update" to switch between branches is mentioned in http://potrou.net/hgdevguide/setup.html#getting-the-source-code and also http://potrou.net/hgdevguide/coredev.html#read-write-checkout and also in http://potrou.net/hgdevguide/committing.html#porting-within-a-major-version. But a dedicated FAQ entry could be added. Regards Antoine.

On 25.02.2011 17:12, Barry Warsaw wrote:
Two scenarios are possible: * You make a clone per branch with the full history, with the current branch being different in each of those. Since "hg update" updates to the head of the current branch, this should be easy to do. When you pull from the single repo you will get changes for the other branches as well, but they will not bother you. * You make a clone per branch, containing *only* the respective branch (with its ancestors). This is done by using "URI#branchname" as the source when cloning/pulling. Both should work equally well, with the former giving larger repository sizes, and the latter taking somewhat longer on the initial clone. Georg

On 2011-02-25 17:12, Barry Warsaw wrote:
I know (almost) nothing about developing Python (this is my first post to this list after lurking for quite a while now), but as a regular Mercurial contributor, I think the following could be useful for you: First, get an initial clone (let's name it 'master') over the wire using: [1] $ hg clone -U ssh://hg@hg.python.org/cpython master Then create a hardlinked clone [2] for working in each branch, specifying the branch to check out using option -u: $ hg clone master py26 -u 2.6 updating to branch 2.6 NNN files updated, 0 files merged, 0 files removed, 0 files unresolved $ hg clone master py27 -u 2.7 updating to branch 2.7 NNN files updated, 0 files merged, 0 files removed, 0 files unresolved $ hg clone master trunk -u trunk updating to branch trunk NNN files updated, 0 files merged, 0 files removed, 0 files unresolved $ hg clone master py31 -u 3.1 updating to branch 3.1 NNN files updated, 0 files merged, 0 files removed, 0 files unresolved $ hg clone master py32 -u 3.2 updating to branch 3.2 NNN files updated, 0 files merged, 0 files removed, 0 files unresolved This will be fast and save space as these local 'branch clones' will share diskspace inside .hg/store by using hardlinks, and you need to do the initial slow clone over the wire only once. 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://hg@hg.python.org/cpython instead, you'd want to edit the [paths] section in the .hg/hgrc file in each of the branch repos. But of course you can also leave the default paths as they are and synchronize via the master repo (e.g. pull new changesets into master first, and then pull into the specific branch repo). [1] http://selenic.com/repo/hg/help/clone [2] http://mercurial.selenic.com/wiki/HardlinkedClones [3] http://www.selenic.com/mercurial/hgrc.5.html#paths [4] http://selenic.com/repo/hg/help/urls

On Feb 25, 2011, at 06:40 PM, Adrian Buehlmann wrote:
Thanks very much Adrian, this is exactly what I was looking for. It maps almost directly to my current mental model for working on Python in Subversion (and truth be told, also how I do/did it with Bazaar). 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. 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. I'll have to remember that 'hg pull' does not update the working copy by default, and eventually I'll figure out the whole merge thing. 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. It doesn't look like this is possible with 'hg commit' though, right? Cheers, -Barry

On Fri, 25 Feb 2011 14:43:15 -0500 Barry Warsaw <barry@python.org> wrote:
I'll have to remember that 'hg pull' does not update the working copy by default, and eventually I'll figure out the whole merge thing.
You can use "hg pull -u" to update (and "hg pull -uv" if you want to see the list of updated files).
Should be customizable: http://mercurial.selenic.com/wiki/CommitMessageTemplate http://mercurial.selenic.com/wiki/DiffsInCommitMessageInVIM (never tried myself) Regards Antoine.

On 25/02/2011 20:43, Barry Warsaw wrote:
What you are asking for is available in TortoiseHg which absolutely rocks (if you are not allergic to the idea of a graphical tool). You can even select indvidually inside a file which lines to commit or not. A bit risky but very handy when you have a few oneliners to commit or not to commit. cheers, Philippe

On Feb 25, 2011, at 09:04 PM, Philippe Fremy wrote:
What you are asking for is available in TortoiseHg which absolutely rocks (if you are not allergic to the idea of a graphical tool).
Like shellfish, bee-strings, and Perl I'm afraid. :)
You mean, TortoiseHg supports incremental commits on a single file? That's kind of neat, but scary. ;) -Barry

Barry Warsaw writes:
You mean, TortoiseHg supports incremental commits on a single file? That's kind of neat, but scary. ;)
Darcs people have been doing this for, well, for as long as Darcs has existed. It's not scary at all. In fact, in Darcs you can select hunks across files, too.

On 25Feb2011 14:43, Barry Warsaw <barry@python.org> wrote: | [...] 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. Hmm. Why do you need to fiddle with the hgrc? Just curious. | I'll have to remember that 'hg pull' does not update the working copy by | default, and eventually I'll figure out the whole merge thing. "hg fetch" does though. That's my usual incanation. | 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. It doesn't look like this is possible with 'hg | commit' though, right? CVS had that problem. I had a wrapper somewhere that masquerades as $EDITOR and writes a diff into the commit buffer as you describe. [ Digs through my hg repository... ] Ok; then it took the form of a script called "cvscommit" that set $EDITOR to the command "cvscommit-editor", wrote the diff stuff, invoked "cvs commit". That ran "cvscommit-editor", which invoked the old $EDITOR and off you went. I would think editing the hgrc to set the hg editor and using the commit hooks would streamline this for Mercurial so you could do the usual "hg commit" command without going through the outer wrapper. I'll devote a little time today, since I've missed this little hack:-( Interested? Cheers, -- Cameron Simpson <cs@zip.com.au> DoD#743 http://www.cskk.ezoshosting.com/cs/ We don't just *borrow* words; on occasion, English has pursued other languages down alleyways to beat them unconscious and rifle their pockets for new vocabulary. - James D. Nicoli

Hi, Le 25/02/2011 20:43, Barry Warsaw a écrit :
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.ht...
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

On Feb 26, 2011, at 01:49 AM, Éric Araujo wrote:
So let's start from the basics. I want separate working directories for each active line-of-development (I'll use that term instead of "branch"), e.g. working directories containing the tip of the 2.6 LoD, 2.7, 3.1, 3.2, and 3.3. I will not be doing feature or bug development in any of these directories. They are purely for local tracking of the remote masters. Thus, I want to be able to synchronize any one of those LoDs against the remote master with one command, like I would using Subversion's 'svn up'. 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 (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.) 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.
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.
This is an inevitable problem with trying to converse fluently about three major dVCSs and at least one or two other non-dVCSs. They all use the same words to mean vaguely similar things, but quickly get bogged down in the implementation details assigned to those words. It all makes perfect sense when you've been immersed in those technologies, but it makes discussions and comparisons exceedingly difficult. I've no doubt it's doubly painful to many people who have no prior experience with a dVCS. (Aside: Bazaar could have potentially eased these folks transition because you can use Bazaar just like you would Subversion - as a centralized VCS -- without stopping others from using it with full dVCS features on the same code base. I don't know if Mercurial offers the same flexibility.) It's a little like trying to teach Python to a Java programmer. "Object", "Class", "Instance", "Import" all mean roughly similar things, which lulls you into a false sense of understanding. We learn by holding up the new to the light of the familiar and looking for interference patterns. :)
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.
Great, I'll try that, thanks. One thing Mercurial and Bazaar definitely share is a wealth of magical awesomeness hidden in manpages, wiki pages, mailing list posts, people's heads, configuration files, and source code. :)
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. 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. :) -Barry

On Sat, 26 Feb 2011 13:08:47 -0500, Barry Warsaw <barry@python.org> wrote:
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.
I agree with you that I don't trust the 'svn switch' style. I also find it slow. However....
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

On Feb 26, 2011, at 02:05 PM, R. David Murray wrote:
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. ;)
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.
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. -Barry

On Sat, 26 Feb 2011 16:06:45 -0500 Barry Warsaw <barry@python.org> wrote:
Often (but not always), when you're wanting to do something, there's an extension for Mercurial which can be enabled ;) http://mercurial.selenic.com/wiki/ShareExtension Regards Antoine.

On 2011-02-26 22:06, Barry Warsaw wrote:
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?
You can use 'hg paths' for that: See http://selenic.com/repo/hg/help/paths or 'hg help paths' on the command line.
I'm quite surprised indeed to read that much about Bazaar in this thread here :)

On Feb 26, 2011, at 11:45 PM, Adrian Buehlmann wrote:
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.
Well, I guess it's doubtful I'd change his mind then. :)
Do you know how thorough 'bzr check' is? I don't, but then I've never used it or felt the need to. ;)
Oh, and 'bzr info' always tells you what the push and pull locations are.
You can use 'hg paths' for that:
Nice, thanks. -Barry

On 2011-02-27 01:50, Barry Warsaw wrote:
Yep.
That's quite amazing. If I talk with people about that, it often turns out that they don't check the integrity of their repos. Well, hg verify *is* through and fast enough. That's good enough for me. And being slow is not sufficient to earn my trust. FWIW, be aware that Mercurial does not do integrity checks on normal operations, so chances are you will be able to use a repo that fails verify for quite a while -- without even noticing it. For example you can remove *some* file X inside .hg/store/data and continue to add history to that repo without any sign of errors, as long as the file X isn't used during the operations you do.

On Sat, Feb 26, 2011 at 10:08, Barry Warsaw <barry@python.org> wrote:
For other people's benefit, LoD == line of development (I think).
That's one way of doing it.
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.
So does Hg: simply edit your .hgrc to have it both pull and push to the same URL. 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.
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.
Neither do I in an svn context and why Hg does let you check out just a branch and have all pulls and pushes only go to that branch.
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.
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.
As I said above, use the #<branch> format and you skip this issue (I think).
Hg's is the mq (Mercurial Queue) extension.
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).

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'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.
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.
Right, see my follow up to RDM.
That might be a better way if it doesn't slurp down the entire repository history.
Yep, I get all that. It's Mercurial's model of the world.
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. :)
No really, I do get all that! I just don't like it much. Maybe it'll grow on me though.
I think mq is more like quilt than shelve. The moral equivalents in Bazaar would probably be the loom and pipeline extensions.
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

On Sat, Feb 26, 2011 at 1:37 PM, Brett Cannon <brett@python.org> wrote:
There is hg-git, but that is hg on top of git.
Actually, hg-git is bidirectional. The hg-git documentation is written from the perspective of an hg client talking to a git server, but for a DVCS "client" and "server" are a matter of perspective. I spent some time on Friday setting up hg-git on my workstation and making a few test commits. It took me awhile to figure out how to get everything working, but it seems to work smoothly now. At some point I'll update http://wiki.python.org/moin/Git with instructions. -- Daniel Stutzbach

On Sat, Feb 26, 2011 at 3:09 PM, Brett Cannon <brett@python.org> wrote:
Hg's is the mq (Mercurial Queue) extension.
I prefer the hg shelve plugin (http://mercurial.selenic.com/wiki/ShelveExtension) for this, more intuitive to me

On Feb 26, 2011, at 01:49 AM, Éric Araujo wrote:
Except it doesn't quite work the way I want it to (hg 1.6.3). It opens your editor with two files, one is the commit message and the other is the diff. (The script itself is a bit buggy too. ;) But it's a good clue, and I've modified the default hgeditor script to get closer, and fix the bug I noticed. I basically append the diff to the temporary log message file. It's still not right though because if the diff lines aren't prepended with 'HG:', they end up in the commit message. Arg. Oh well, I can clearly hack a more complicated script together. It's such a blindingly obvious improvement, it's too bad 'hg commit' doesn't DTRT by default. -Barry

On 26.02.2011 21:49, Barry Warsaw wrote:
While I understand the usefulness of the diff feature, it is not useful to everyone, e.g. those using almost exclusively ``commit -m message``. Of course it would be nice if hg made it easier (a hgrc option, for example) to do this. BTW, I had not heard of hgeditor before, and wrote a small hg extension to do what you want (with HG: prefix :) before I saw that others had already replied with hgeditor. The extension had 10 lines of code. Georg

On Feb 27, 2011, at 05:38 PM, Georg Brandl wrote:
While I understand the usefulness of the diff feature, it is not useful to everyone, e.g. those using almost exclusively ``commit -m message``.
The editor window doesn't pop up when you provide the -m flag, so the diff output is not relevant.
Of course it would be nice if hg made it easier (a hgrc option, for example) to do this.
Sure.
We should find a place (i.e. repository) to stash these useful add-ons and hacks so that all Python developers can find them. -Barry

On Mon, 28 Feb 2011 10:08:26 -0500 Barry Warsaw <barry@python.org> wrote:
I think you can simply add them somewhere on the hg wiki: http://mercurial.selenic.com/wiki/ and then link to the pages from our own wiki, or the developer's FAQ. Regards Antoine.

Hi, As a mercurial user, I thank you for this effort! One question, where/how do I send suggestion to what to add into .hgignore file? In particular, I found these dynamically generated files after a build in Windows (3.2) that probably should be entered as .hgignore entries: ? PC/python_nt_d.h ? PC/pythonnt_rc_d.h ~/santa On Mon, Feb 28, 2011 at 1:10 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:

[...] publishing patches by referring to a remote repository,
rather than uploading the diff.
Is this a recommended workflow at this point, or should we generate/attach patch files still? Both, for experimentation? ~/santa On Fri, Mar 4, 2011 at 1:15 PM, "Martin v. Löwis" <martin@v.loewis.de>wrote:

Le vendredi 04 mars 2011 à 14:03 -0800, Santoso Wijaya a écrit :
Pragmatically, I think we would still prefer patches, but Mercurial should make it much easier to maintain them - e.g. you can use mq (which is what Mercurial devs themselves use, actually). We can also experiment with other forms of publishing changes, but I think that would require the publisher to somehow collapses their own changesets, so that it finally amounts to reviewing a patch. In my opinion at least, it would be bad if we started integrating intermediate changesets leading to a final patch just because Mercurial allows us to do it. I think it's better if the public history line doesn't get obscured with work-in-progress changesets. Regards Antoine.

On Fri, 04 Mar 2011 13:01:02 -0800, Santoso Wijaya <santoso.wijaya@gmail.com> wrote:
I, on the other hand, would like to see .rej and .orig removed from the ignore list. I don't like having these polluting my working directory, and 'hg status' is the easiest way to find them (if they aren't ignored). Or if there's some way to configure my personal .hgrc to ignore those particular ignore lines, that would be fine too :) -- R. David Murray www.bitdance.com

On 6 March 2011 00:44, R. David Murray <rdmurray@bitdance.com> wrote:
If those were to be removed from .hgignore then there would be a high likelihood of someone doing "hg addremove" and inadvertently tracking them. The purpose of .hgignore is to prevent inadventently tracking files that shouldn't be tracked. "hg status -i" will list all ignored files that are present in your working directory. For other options, "hg help status". Tim Delaney

On Sun, 06 Mar 2011 00:54:39 +1100, Tim Delaney <timothy.c.delaney@gmail.com> wrote:
Ah, well, I don't like that UI. The purpose for me of .hgignore (and similar ignore files) is to make the status command show any files that have been modified or aren't normal build/run products. I'd rather add and remove files individually by hand (except when adding or removing a directory). I also want a --strict option for the commit command that refuses to commit if there are unignored unadded or missing files. (--strict is the bzr spelling; I don't care about the spelling :)
"hg status -i" will list all ignored files that are present in your working directory. For other options, "hg help status".
hg status -i is useless because there are a *lot* of ignored files in a working directory where python has been built. I'd have to do a distclean first, which would mean I'd have to do a rebuild after...and all of that just takes too long :) I guess I have some hg hacking in my future, unless someone has already written extensions for this stuff. -- R. David Murray www.bitdance.com

On Sat, 5 Mar 2011 08:36:04 -0800 Daniel Stutzbach <stutzbach@google.com> wrote:
Well, it's more user-friendly to help "hg addremove" work as expected, rather than add hooks down the line to forbid pushing any mistakes. Regards Antoine.

With hg 1.7.5 on Windows 7 I performed a non-core checkout: hg clone http://hg.python.org/cpython The eol extension is enabled in global settings. I looked at things a bit, opening some files and using the Tortoise Hg Repository Explorer. But made no actual changes. Running hg diff produces a large amount of output with almost all the *.decTest and most of the Windows build files (*.mk, *.sln, *.vcproj, *.bat) showing as changed but with identical text. I've had problems like this with Hg before (http://mercurial.selenic.com/bts/issue2287). The situation can be fixed by hg update to another version and then back to default. Neil

On Fri, 25 Feb 2011 19:13:49 +1100 Neil Hodgson <nyamatongwe@gmail.com> wrote:
Yes, please try to disable it. The issue is we have a .hgeol in the repository right now (it's in the SVN repository too), but it doesn't match the reality of on-disk files, so when you update, the eol extension tries to "fix" those files. Regards Antoine.

On Fri, 25 Feb 2011 13:52:58 +0100 Antoine Pitrou <solipsis@pitrou.net> wrote:
It should now be fixed in current SVN, meaning the final conversion should be perfectly usable with the eol extension enabled. Do you find other issues under Windows? Have you tried pushing changes? Regards Antoine.

Antoine Pitrou:
It should now be fixed in current SVN, meaning the final conversion should be perfectly usable with the eol extension enabled.
Good.
Do you find other issues under Windows? Have you tried pushing changes?
Since I'm not a member of core developers I used a http pull and can't push: C:\u\cpython>hg push pushing to http://hg.python.org/cpython searching for changes remote: ssl required Neil

On Fri, Feb 25, 2011 at 10:19 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Would it be possible to name "trunk" as "2.x" instead? Otherwise I could see people getting confused and asking why trunk was closed, and/or not the same as "default". Looking very nice, though! :) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On Sat, 26 Feb 2011 12:32:04 +1000 Nick Coghlan <ncoghlan@gmail.com> wrote:
That was my first idea, but then I realized that the branch includes 1.x and even pre-1.0 commits, so "2.x" might actually be more confusing/misleading and hide the fact that the full trunk history is there. I think people should simply get used to the idea that "default" is /the/ main branch in Mercurial (*). It's even easier to remember IMHO ("trunk" sounds a bit obscure at first, for a non-native English speaker). (*) but it's not any special really, it's just the branch you get by... default ;) Regards Antoine.

On 26/02/2011 14:44, Antoine Pitrou wrote:
Well, except for the prevalence of "trunk" as terminology to mean "place where current development happens". It will lead to odd conversations like: "is trunk the trunk?", "no trunk is what used to be trunk, default is now trunk". Renaming it "legacy-trunk" is no less precise, but more explicative. Michael
-- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html

Although I now admit "legacy-trunk" sounds quite accurate, and conveys a clear warning to anyone wondering if they should use it.
To stay in tree terminology, I propose "stump" (*). Or "rotten-trunk". Bikeshedding is such a fun activity :-) Regards, Martin (*) m-w.com: "the part of a plant and especially a tree remaining attached to the root after the trunk is cut"

On Sat, 26 Feb 2011 17:49:32 +0100 Éric Araujo <merwok@netwok.org> wrote:
IMO, a dummy merge at the tip of the default branch may confuse users looking at the history, especially if they try a graphical display of the DAG (e.g. "hg glog" or the graph page in the Web UI). Besides, it would precisely make it harder to distinguish between trunk and py3k development at the time both took place in parallel. Regards Antoine.

On Sun, Feb 27, 2011 at 3:00 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Besides, it would precisely make it harder to distinguish between trunk and py3k development at the time both took place in parallel.
With the legacy branches now being closed so they don't appear in the default output from hg commands, I'm fine with keeping the old "trunk" name from SVN. It was only when those commands were displaying both "trunk" and "default" that it bothered me. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

The dummy merge would not stay long: The commits targeted at 3.3 would be its children.
Besides, it would precisely make it harder to distinguish between trunk and py3k development at the time both took place in parallel.
IIUC, there would be two parallel lines of history (unnnamed branches). Would that be hard to read? Regards

On Sat, Feb 26, 2011 at 8:44 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Maybe I don't fully understand how Mercurial branches work or how it defines terminology (in fact, that is likely :) ). What's the difference between the statement "trunk changesets are strict ancestors of 2.7" and the statement "trunk's history is a strict subset of 2.7's history"? -- Daniel Stutzbach

Named branches are exclusive, they can't be a subset of each other ;)
Actually, they can. Take the example of the Mercurial repo itself. They fix bugs in the stable branch and add features in default. When they merge stable into default and commit, default becomes a superset of stable. That is to say, someone pulling default also gets the changesets from stable that are ancestors of the merge changset. Or in other words, if you check out default, you get all bug fixes from stable. HTH

A Mercurial 'merge' <http://mercurial.selenic.com/wiki/Branch> is simply a creation of another changeset, which has two parents: the current tip of the branch you're working on, and the changeset you are merging with. ~/santa On Sat, Feb 26, 2011 at 10:23 AM, Barry Warsaw <barry@python.org> wrote:

Le samedi 26 février 2011 à 09:27 -0800, Daniel Stutzbach a écrit :
Apparently you overlooked the first statement: "Named branches are exclusive". In other words, a changeset can be in only one named branch. So it's impossible for a branch to be a subset or superset of another. (except the trivial case of an empty branch :-)).

Am 26.02.2011 17:44, schrieb Antoine Pitrou:
But is there a need to have any changesets in the "trunk" named branch? Couldn't the historical changesets just be in an unnamed branch, being ancestor of so many named branches? I'd like to prevent people from mistakenly committing onto the trunk, which would be easiest if trunk didn't exist at all. Regards, Martin

Le samedi 26 février 2011 à 18:36 +0100, "Martin v. Löwis" a écrit :
There is no such thing as an "unnamed branch". What would "hg branches" show? An empty space?
I'd like to prevent people from mistakenly committing onto the trunk, which would be easiest if trunk didn't exist at all.
Well, the push you request in the todo should do the trick. We can also call it "legacy-trunk", too :) Regards Antoine.

hg branches doesn't list unnamed branches. "hg heads" omits any branch name for unnamed branches. See the cpythonextras repository for examples: changeset: 72694:e65daae6cf44 user: Antoine Pitrou <solipsis@pitrou.net> date: Mon Feb 21 21:30:55 2011 +0000 summary: Try s/UINT_MAX/INT_MAX/ This is listed as a head, but not of a named branch.
Yes, that would also work. However, when then somebody proposed that we may not need the trunk branch at all in the conversion result (which I still think is the case - we don't need it), I noticed that this would solve the problem in a more clean manner.
We can also call it "legacy-trunk", too :)
I think we can do better. I also dislike "hg log --only-branch default" to only go back to 2006 (to aeefba456e4d), when this revision actually does have a parent (namely, on the trunk branch, 4b41806a0326). So I would propose this attribution to branches: - everything that is ancestor of the default branch is attributed to the default branch, back to the very beginning of the repository. - Everything currently on trunk that wouldn't be on default is then attributed to the oldest branch that it is an ancestor of, in the order 2.0, 2.1, 2.2, ... 2.7. So e.g. the 2.7 branch would go back to where it branched from the 2.6 branch (after the actual creation of the 2.6 branch in svn), which would go back to where it branched from 2.5, and so on. Regards, Martin

It's not on an unnamed branch, it's on the "default" branch (which is omitted for concision by "hg log" and other commands with a similar output).
But you *need* the changesets from the trunk branch. You are just arguing for giving them another label (including "" or "default"), hence:
I'm not convinced that small quirks of using "hg log" are important at this point. Also, you could try other options of "hg log" such as "--follow". If we called ex-trunk the same name as ex-py3k ("default"), things would probably be quite more confusing, since inspecting a changeset wouldn't tell you immediately where it comes from (2.x or 3.x development). Regards Antoine.

It's probably a terminology issue, but: the changeset can't be "on" the default "branch", because the head of the default branch (called "tip", IIUC) isn't a descendant of that changeset. It's parent is changeset: 72693:d9769c8a828b user: Antoine Pitrou <solipsis@pitrou.net> date: Mon Feb 21 21:25:39 2011 +0000 summary: temp branch to debug crashes on snow leopard buildbot so you have called it "temporary branch" in subversion. I got go with that term also, if "unnamed branch" is confusing.
IIUC, --follow doesn't help. It traces history across renames and copies, which is not what I want to overcome when trying to produce the full history of the py3k branch. As for "small quirks ... important at this point": this point is the *only* chance to get it right. If you get it wrong now, we will have to deal with it forever (or rather until we switch to the next version control system). If you chose to convert in the way it currently does: fine with me, as long as the choice was deliberate (rather than coincidental).
I would it call default only up to the point where the py3k branch was branched off trunk. All changes up to this point actually *do* belong to both branches. Python 3's history goes all the way back to 0.9, and I'm sure you can still find code in 3.2 which was written 20 years ago. Change sets created after 3.x was forked off should certainly live on a separate mercurial branch - it would be reasonable to call this branch then 2.x. Regards, Martin

On Sun, 27 Feb 2011 08:09:21 +0100 "Martin v. Löwis" <martin@v.loewis.de> wrote:
Well, a branch (or named branch) in hg terminology can have several heads (see the other email about heads and branches). Also, just so you know, "tip" is simply the latest (in pull or commit order) changeset in the local repository. It can be in any branch (for example, if you pull of bunch of changesets someone made in "3.2", then your tip will be in branch "3.2"). I hope it all starts to make sense ;) Regards Antoine.

On Sat, Feb 26, 2011 at 9:55 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
There is no such thing as an "unnamed branch". What would "hg branches" show? An empty space?
I understand now why I was confused. I had previously read the sentence "Both Git and Mercurial support unnamed local branches." at http://mercurial.selenic.com/wiki/BranchingExplained But as I dig deeper, I see that there is only one unnamed branch, and it actually does have an implicit name: "default". It appears Mercurial supports at least three different kinds of branching: cloning (similar to Bazaar), bookmarks (similar to git), and named branches. So a named branch can contain more than one branch. Were there reasons for going with named branches over bookmarks? PEP 385 discusses only cloning and named branches. I'm just curious, not trying to start a long discussion. :-) -- Daniel Stutzbach

From http://mercurial.selenic.com/wiki/Branch#Named_branches:
[...] a good rule of thumb is to use branch names sparingly and for rather longer lived concepts like "release branches" (rel-1, rel-2, etc) and rather not for short lived work of single developers So I think named branches make sense here. Bookmarks are really for potential branches, experimental features, for example, for easier navigation for the developer's convenience. Named branches, on the other hand, are better for posterity reasons. ~/santa On Sat, Feb 26, 2011 at 10:40 AM, Daniel Stutzbach <stutzbach@google.com>wrote:

On Sat, 26 Feb 2011 10:40:03 -0800 Daniel Stutzbach <stutzbach@google.com> wrote:
Ok, so beware, the term "branch" can conflate two concepts: - a path in the topology (or line of development) - a "named branch" in hg terminology So, actually, hg promotes a slightly different terminology: - a "head" is a changeset without a child in the topology - a "branch" usually means a "named branch": a set of changesets bearing the same label (e.g. "default"); that label is freely chosen by the committer at any point, and enforces no topological characteristic (even though in practice it will have, since it's the whole point from the user's perspective, and also because hg's default behaviour and concept of a "current branch" encourages it) A (named) branch can have zero, one, or several heads: - zero head: if all branch-local heads have a child in another named branch (for example, "trunk" is linearly followed by "2.7") - several heads: if several lines of development were started in this branch without bothering to give them separate names When you have several heads on a branch, you can merge them together if you want to reconcile the lines of development they represent. When you have several branches with at least one head each, you can also merge them together: you must be careful to choose which named branch the merge changeset will be part of (for example, if you want to merge "3.1" into "3.2", you will certainly want the merge changeset to be part of "3.2", otherwise "3.1" will get a lot of unwanted features ;-)). Note: a branch with zero head is marked "inactive" in "hg branches". This basically means that it has already been merged in another branch. (of course, you can still develop in that branch, which will certainly create a new head as soon as you commit your first new changeset) Regards Antoine.

From: Antoine Pitrou
There are *some* topological restrictions, because hg won't let you assign a branch name that's been used before to a node unless one of its parents has that name. So you can't create two disconnected subgraphs whose nodes have the same branch name. -- Greg This email may be confidential and subject to legal privilege, it may not reflect the views of the University of Canterbury, and it is not guaranteed to be virus free. If you are not an intended recipient, please notify the sender immediately and erase all copies of the message and any attachments. Please refer to http://www.canterbury.ac.nz/emaildisclaimer for more information.

On 2011-02-26 23:26, Greg Ewing wrote:
That's not completely correct. You *can* do that. Mercurial by default assumes you're probably in error if you are trying to create such disconnected branch name subgraphs, but you can convince it that it's really what you want by doing: hg branch --force <existing branch name> Example (glog command requires the graphlog extension enabled [1]): $ hg init a $ cd a $ echo foo > bla $ hg ci -Am1 adding bla $ hg branch b1 marked working directory as branch b1 $ hg ci -m2 $ hg branch default abort: a branch of the same name already exists (use 'hg update' to switch to it) $ hg branch --force default marked working directory as branch default $ hg ci -m3 created new head $ hg glog --template "{rev}, {branch}\n" @ 2, default | o 1, b1 | o 0, default [1] http://mercurial.selenic.com/wiki/GraphlogExtension

So, actually, hg promotes a slightly different terminology: - a "head" is a changeset without a child in the topology
So what do you call the LoD leading up to a head? (i.e. the set of changesets that are ancestors of a head and not ancestors of any other head) Regards, Martin
participants (23)
-
"Martin v. Löwis"
-
Adrian Buehlmann
-
Antoine Pitrou
-
Barry Warsaw
-
Brett Cannon
-
Cameron Simpson
-
Daniel Stutzbach
-
Dirkjan Ochtman
-
Dj Gilcrease
-
Eli Bendersky
-
Ethan Furman
-
Georg Brandl
-
Greg Ewing
-
Michael Foord
-
Neil Hodgson
-
Nick Coghlan
-
Philippe Fremy
-
R. David Murray
-
Raymond Hettinger
-
Santoso Wijaya
-
Stephen J. Turnbull
-
Tim Delaney
-
Éric Araujo