Re: [Python-Dev] Mercurial conversion repositories
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 solip...@pitrou.net wrote: On Mon, 28 Feb 2011 16:07:48 -0500 Barry Warsaw ba...@python.org wrote: On Feb 28, 2011, at 04:15 PM, Antoine Pitrou wrote: On Mon, 28 Feb 2011 10:08:26 -0500 Barry Warsaw ba...@python.org wrote: 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. We should find a place (i.e. repository) to stash these useful add-ons and hacks so that all Python developers can find them. 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. If they're of general use to the hg community, sure. Otherwise, it might be good to have a place of our own for our own repository tools. Well, your diff-in-the-commit-editor-window is certainly not CPython-specific ;) Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/santoso.wijaya%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
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: All patches should go to the bug tracker. If you host a clone somewhere, you could start publishing patches by referring to a remote repository, rather than uploading the diff. I'm curious how this DVCS thing works out for contributors. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
[...] 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 mar...@v.loewis.dewrote: 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: All patches should go to the bug tracker. If you host a clone somewhere, you could start publishing patches by referring to a remote repository, rather than uploading the diff. I'm curious how this DVCS thing works out for contributors. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
Le vendredi 04 mars 2011 à 14:03 -0800, Santoso Wijaya a écrit : [...] 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? 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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
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. 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. 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 signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
On Mon, 28 Feb 2011 10:08:26 -0500 Barry Warsaw ba...@python.org wrote: 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. We should find a place (i.e. repository) to stash these useful add-ons and hacks so that all Python developers can find them. 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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
On Feb 28, 2011, at 04:15 PM, Antoine Pitrou wrote: On Mon, 28 Feb 2011 10:08:26 -0500 Barry Warsaw ba...@python.org wrote: 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. We should find a place (i.e. repository) to stash these useful add-ons and hacks so that all Python developers can find them. 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. If they're of general use to the hg community, sure. Otherwise, it might be good to have a place of our own for our own repository tools. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
On Mon, 28 Feb 2011 16:07:48 -0500 Barry Warsaw ba...@python.org wrote: On Feb 28, 2011, at 04:15 PM, Antoine Pitrou wrote: On Mon, 28 Feb 2011 10:08:26 -0500 Barry Warsaw ba...@python.org wrote: 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. We should find a place (i.e. repository) to stash these useful add-ons and hacks so that all Python developers can find them. 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. If they're of general use to the hg community, sure. Otherwise, it might be good to have a place of our own for our own repository tools. Well, your diff-in-the-commit-editor-window is certainly not CPython-specific ;) Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
On Sun, 27 Feb 2011 08:09:21 +0100 Martin v. Löwis mar...@v.loewis.de wrote: changeset: 72694:e65daae6cf44 user:Antoine Pitrou solip...@pitrou.net date:Mon Feb 21 21:30:55 2011 + summary: Try s/UINT_MAX/INT_MAX/ 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). 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. 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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
On 26.02.2011 21:49, Barry Warsaw wrote: On Feb 26, 2011, at 01:49 AM, Éric Araujo wrote: 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. 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. 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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
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). +1. People will recognize trunk as a svn think. If that doesn't clue them in, they will ask, and every other person will know. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
Antoine Pitrou wrote: On Sat, 26 Feb 2011 12:32:04 +1000 Nick Coghlan ncogh...@gmail.com wrote: On Fri, Feb 25, 2011 at 10:19 AM, Antoine Pitrou solip...@pitrou.net wrote: $ hg branches default68026:f12ef116dd10 3.268025:cef92ee1a323 2.768010:8174d00d0797 3.167955:5be8b695ea86 2.667287:5e26a860eded 2.565464:e4ecac76e499 trunk 62750:800f6c92c3ed 3.060075:1d05144224fe 2.458552:df72cac1899e 2.345731:a3d9a9730743 2.240444:d55ddc8c8501 2.130171:06fcccf6eca8 2.018214: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. 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. 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. Maybe prePy3k, then? Trunk, after all, is not very descriptive. Or is that name also inaccurate? ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
On Sat, Feb 26, 2011 at 4:34 PM, Georg Brandl g.bra...@gmx.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. Problem is, you then have 1.5.2 released from the 2.x branch :) In that case, legacy-trunk would seem clearer. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
On Sat, Feb 26, 2011 at 7:29 PM, Martin v. Löwis mar...@v.loewis.de wrote: 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). +1. People will recognize trunk as a svn think. If that doesn't clue them in, they will ask, and every other person will know. But why not choose a name where they don't even have to ask? Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
Le dimanche 27 février 2011 à 00:42 +1000, Nick Coghlan a écrit : On Sat, Feb 26, 2011 at 7:29 PM, Martin v. Löwis mar...@v.loewis.de wrote: 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). +1. People will recognize trunk as a svn think. If that doesn't clue them in, they will ask, and every other person will know. But why not choose a name where they don't even have to ask? Doesn't trunk represent exactly what it is (the former SVN trunk)? Other names would probably be less exact or less precise. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
On 26/02/2011 14:44, Antoine Pitrou wrote: Le dimanche 27 février 2011 à 00:42 +1000, Nick Coghlan a écrit : On Sat, Feb 26, 2011 at 7:29 PM, Martin v. Löwismar...@v.loewis.de wrote: 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). +1. People will recognize trunk as a svn think. If that doesn't clue them in, they will ask, and every other person will know. But why not choose a name where they don't even have to ask? Doesn't trunk represent exactly what it is (the former SVN trunk)? Other names would probably be less exact or less precise. 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 Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- 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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
On Sat, 26 Feb 2011 15:44:08 +0100 Antoine Pitrou solip...@pitrou.net wrote: Le dimanche 27 février 2011 à 00:42 +1000, Nick Coghlan a écrit : On Sat, Feb 26, 2011 at 7:29 PM, Martin v. Löwis mar...@v.loewis.de wrote: 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). +1. People will recognize trunk as a svn think. If that doesn't clue them in, they will ask, and every other person will know. But why not choose a name where they don't even have to ask? Doesn't trunk represent exactly what it is (the former SVN trunk)? Other names would probably be less exact or less precise. Although I now admit legacy-trunk sounds quite accurate, and conveys a clear warning to anyone wondering if they should use it. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
Am 26.02.2011 15:42, schrieb Nick Coghlan: On Sat, Feb 26, 2011 at 7:29 PM, Martin v. Löwis mar...@v.loewis.de wrote: 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). +1. People will recognize trunk as a svn think. If that doesn't clue them in, they will ask, and every other person will know. But why not choose a name where they don't even have to ask? That could be better. Unfortunately, nobody has proposed a name that has this property and is also correct. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
On Fri, Feb 25, 2011 at 6:32 PM, Nick Coghlan ncogh...@gmail.com 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. Can we just get rid of trunk altogether? It's history is a strict subset of the 2.7 branch's history, isn't it? -- Daniel Stutzbach ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
Le samedi 26 février 2011 à 08:38 -0800, Daniel Stutzbach a écrit : On Fri, Feb 25, 2011 at 6:32 PM, Nick Coghlan ncogh...@gmail.com 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. Can we just get rid of trunk altogether? It's history is a strict subset of the 2.7 branch's history, isn't it? Named branches are exclusive, they can't be a subset of each other ;) (in other words: 2.7 starts where trunk stops; trunk changesets are strict ancestors of 2.7) Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
Le 26/02/2011 17:44, Antoine Pitrou a écrit : Can we just get rid of trunk altogether? It's history is a strict subset of the 2.7 branch's history, isn't it? Named branches are exclusive, they can't be a subset of each other ;) Can we just use default for trunk and py3k? For the time when both trunk and py3k were active, it would create two unnamed branches on the default branch, but one merge would solve that. Regards ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
On Sat, 26 Feb 2011 17:49:32 +0100 Éric Araujo mer...@netwok.org wrote: Le 26/02/2011 17:44, Antoine Pitrou a écrit : Can we just get rid of trunk altogether? It's history is a strict subset of the 2.7 branch's history, isn't it? Named branches are exclusive, they can't be a subset of each other ;) Can we just use default for trunk and py3k? For the time when both trunk and py3k were active, it would create two unnamed branches on the default branch, but one merge would solve that. 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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
On Sun, Feb 27, 2011 at 3:00 AM, Antoine Pitrou solip...@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 | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
Can we just use default for trunk and py3k? For the time when both trunk and py3k were active, it would create two unnamed branches on the default branch, but one merge would solve that. 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). 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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
On Sat, Feb 26, 2011 at 8:44 AM, Antoine Pitrou solip...@pitrou.net wrote: Le samedi 26 février 2011 à 08:38 -0800, Daniel Stutzbach a écrit : Can we just get rid of trunk altogether? It's history is a strict subset of the 2.7 branch's history, isn't it? Named branches are exclusive, they can't be a subset of each other ;) (in other words: 2.7 starts where trunk stops; trunk changesets are strict ancestors of 2.7) 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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
Le samedi 26 février 2011 à 09:27 -0800, Daniel Stutzbach a écrit : On Sat, Feb 26, 2011 at 8:44 AM, Antoine Pitrou solip...@pitrou.net wrote: Le samedi 26 février 2011 à 08:38 -0800, Daniel Stutzbach a écrit : Can we just get rid of trunk altogether? It's history is a strict subset of the 2.7 branch's history, isn't it? Named branches are exclusive, they can't be a subset of each other ;) (in other words: 2.7 starts where trunk stops; trunk changesets are strict ancestors of 2.7) 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? 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 :-)). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
Am 26.02.2011 17:44, schrieb Antoine Pitrou: Le samedi 26 février 2011 à 08:38 -0800, Daniel Stutzbach a écrit : On Fri, Feb 25, 2011 at 6:32 PM, Nick Coghlan ncogh...@gmail.com 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. Can we just get rid of trunk altogether? It's history is a strict subset of the 2.7 branch's history, isn't it? Named branches are exclusive, they can't be a subset of each other ;) (in other words: 2.7 starts where trunk stops; trunk changesets are strict ancestors of 2.7) 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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
Le samedi 26 février 2011 à 18:36 +0100, Martin v. Löwis a écrit : Am 26.02.2011 17:44, schrieb Antoine Pitrou: Le samedi 26 février 2011 à 08:38 -0800, Daniel Stutzbach a écrit : On Fri, Feb 25, 2011 at 6:32 PM, Nick Coghlan ncogh...@gmail.com 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. Can we just get rid of trunk altogether? It's history is a strict subset of the 2.7 branch's history, isn't it? Named branches are exclusive, they can't be a subset of each other ;) (in other words: 2.7 starts where trunk stops; trunk changesets are strict ancestors of 2.7) 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? 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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
On Feb 26, 2011, at 01:49 AM, Éric Araujo wrote: Le 25/02/2011 20:43, Barry Warsaw a écrit : On Feb 25, 2011, at 06:40 PM, Adrian Buehlmann wrote: [snip] Note that each of these branch clones will initially have your local master repo as the default path [3,4]. If you'd like to have the default push/pull path to point to ssh://h...@hg.python.org/cpython instead, you'd want to edit the [paths] section in the .hg/hgrc file in each of the branch repos. I plan on having one clone per branch but pushing and pulling from only one repository, so I don’t need to edit hgrcs. 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://h...@hg.python.org/cpython but I'm not going to remember that url every time. It wouldn't be so bad if Mercurial remembered the pull URL for me, as (you guessed it :) Bazaar does. Anecdote: I migrated from Subversion to Mercurial a few years ago, and found Mercurial branches very intuitive. When I saw mentions of Bazaar branches I was driven nuts by (what I saw as) the conflation between a branch and a clone. Later I understood how it made sense from the perspective of Bazaar, so I shifted my judgment from “insanely confusing” to “a particular choice that I don’t approve” wink. That's funny because to my eyes, Mercurial conflates branches and clones. Why a clone operation should give me the history for all lines-of-development inside a working directory for one arbitrary one strikes me as bizarre (pardon the pun :). I get that for folks who like the svn switch method of working on multiple LoDs, this probably makes a lot of sense. I don't personally like or trust that approach much though. 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. 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. :) 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
Re: [Python-Dev] Mercurial conversion repositories
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? There is no such thing as an unnamed branch. What would hg branches show? An empty space? 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 solip...@pitrou.net date:Mon Feb 21 21:30:55 2011 + summary: Try s/UINT_MAX/INT_MAX/ This is listed as a head, but not of a named branch. 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. 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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
On Feb 26, 2011, at 06:32 PM, Éric Araujo wrote: 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. That makes sense, but correct me if I'm wrong, it's the 'merge' operation that made this happen, right? A merge essentially brings the changesets from one branch into another. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
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? There is no such thing as an unnamed branch. What would hg branches show? An empty space? 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 solip...@pitrou.net date:Mon Feb 21 21:30:55 2011 + summary: Try s/UINT_MAX/INT_MAX/ 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). 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. 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. But you *need* the changesets from the trunk branch. You are just arguing for giving them another label (including or default), hence: 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). 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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
On Sat, Feb 26, 2011 at 9:55 AM, Antoine Pitrou solip...@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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
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 ba...@python.org wrote: On Feb 26, 2011, at 06:32 PM, Éric Araujo wrote: 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. That makes sense, but correct me if I'm wrong, it's the 'merge' operation that made this happen, right? A merge essentially brings the changesets from one branch into another. -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/santoso.wijaya%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
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 stutzb...@google.comwrote: On Sat, Feb 26, 2011 at 9:55 AM, Antoine Pitrou solip...@pitrou.netwrote: 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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/santoso.wijaya%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
On Sat, 26 Feb 2011 13:08:47 -0500, Barry Warsaw ba...@python.org wrote: $ cd py27 # now I want to synchronize $ hg pull -u ssh://h...@hg.python.org/cpython but I'm not going to remember that url every time. It wouldn't be so bad if Mercurial remembered the pull URL for me, as (you guessed it :) Bazaar does. How does setting it in the hgrc differ from remebering it? I've never been comfortable with the bzr --remember option because I'm never sure what it is remembering. Much easier for me to see it in a config file. But, then, that's how my brain works, and other people's will work differently. On Feb 26, 2011, at 01:49 AM, Ãric Araujo wrote: Anecdote: I migrated from Subversion to Mercurial a few years ago, and found Mercurial branches very intuitive. When I saw mentions of Bazaar branches I was driven nuts by (what I saw as) the conflation between a branch and a clone. Later I understood how it made sense from the perspective of Bazaar, so I shifted my judgment from âinsanely confusingâ to âa particular choice that I donât approveâ wink. That's funny because to my eyes, Mercurial conflates branches and clones. Why a clone operation should give me the history for all lines-of-development inside a working directory for one arbitrary one strikes me as bizarre (pardon the pun :). I get that for folks who like the svn switch method of working on multiple LoDs, this probably makes a lot of sense. I don't personally like or trust that approach much though. I agree with you that I don't trust the 'svn switch' style. I also find it slow. However That pull does not update is a feature: The operation between a remote repo and the local repo (the .hg directory) is separate from the operation from the local repo to the working directory. When you know that you want pull + update (like when you have a clean working directory), you use âhg pull -uâ. (I donât like the fetch command.) Sure, I get that. Again, this feature appears odd because I have the full history of all LoDs embedded in a working directory of a single LoD. With the arrangement I outlined above (which is independent of the dVCS backing it), it makes no sense for each LoD working directory to contain all the history of all the other LoDs. In Bazaar, a branch is an independent LoD and it's repository contains only its own history. Sure, it might have identical history with other LoDs up to the point of divergence, and I have ways to efficiently share that history across multiple LoD working directories, but they are still separate and I don't need them if I don't care about them. With Mercurial, all history for all LoDs in a repository always come along for the ride. I find bazaar's model confusing, and hg's intuitive, just like Ãric. And consider that I learned bazaar before mercurial. To me, it makes perfect sense that in a DVCS the unit is a directory containing a repository and a working copy, and that the repository is *the* repository. That is, it has everything related to the project in it, just like the master SVN repository does (plus, since it is a DVCS, whatever I've committed locally but not pushed to the master). To have a repository that only has some of the stuff in it is, IMO, confusing. I advocated for having all the Python history in one repo partly for that reason. I can intellectually see your point about not really *needing* the stuff for the LODs if you are only working on LOD X, but just like 'svn switch' makes me uncomfortable, I'm just not *comfortable* not having the whole repo in there :) As an example, with mercurial, I feel comfortable moving directories around and renaming them (with the help of google it took me about 1 minute to figure out how to keep the association between the repository instances intact). With bazaar I got in trouble trying to do that, because the interrelationship between the working copy directories (and their subsets of the repo?) and the master repo(?) was not clear. I never did figure out how to make it work, I ended up starting over with a new clone. Now, as I get farther into learning mercurial I may well find things that are just as confusing as I found that aspect of bazaar, but at least I am comfortable with the outermost layer: the repo is the repo is the repo. -- R. David Murray www.bitdance.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
On Fri, Feb 25, 2011 at 13:46, Barry Warsaw ba...@python.org wrote: 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 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. You mean, TortoiseHg supports incremental commits on a single file? That's kind of neat, but scary. ;) The record extension lets regular Mercurial do that as well. I think git supports a similar thing. -Brett -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
On Sat, Feb 26, 2011 at 10:08, Barry Warsaw ba...@python.org wrote: On Feb 26, 2011, at 01:49 AM, Éric Araujo wrote: Le 25/02/2011 20:43, Barry Warsaw a écrit : On Feb 25, 2011, at 06:40 PM, Adrian Buehlmann wrote: [snip] Note that each of these branch clones will initially have your local master repo as the default path [3,4]. If you'd like to have the default push/pull path to point to ssh://h...@hg.python.org/cpython instead, you'd want to edit the [paths] section in the .hg/hgrc file in each of the branch repos. I plan on having one clone per branch but pushing and pulling from only one repository, so I don’t need to edit hgrcs. 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'. For other people's benefit, LoD == line of development (I think). 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 That's one way of doing it. (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.) 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. 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://h...@hg.python.org/cpython but I'm not going to remember that url every time. It wouldn't be so bad if Mercurial remembered the pull URL for me, as (you guessed it :) Bazaar does. 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://h...@hg.python.org/cpython#2.7 I believe that might even strip out other history outside the scope of the branch. Anecdote: I migrated from Subversion to Mercurial a few years ago, and found Mercurial branches very intuitive. When I saw mentions of Bazaar branches I was driven nuts by (what I saw as) the conflation between a branch and a clone. Later I understood how it made sense from the perspective of Bazaar, so I shifted my judgment from “insanely confusing” to “a particular choice that I don’t approve” wink. That's funny because to my eyes, Mercurial conflates branches and clones. Why a clone operation should give me the history for all lines-of-development inside a working directory for one arbitrary one strikes me as bizarre (pardon the pun :). 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. 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. 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. 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. This is an inevitable problem with trying to converse fluently about three major dVCSs and at least one or two other non-dVCSs.
Re: [Python-Dev] Mercurial conversion repositories
On Feb 26, 2011, at 01:49 AM, Éric Araujo wrote: 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. 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 signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
On 27 February 2011 01:40, Nick Coghlan ncogh...@gmail.com wrote: On Sat, Feb 26, 2011 at 4:34 PM, Georg Brandl g.bra...@gmx.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. Problem is, you then have 1.5.2 released from the 2.x branch :) In that case, legacy-trunk would seem clearer. +1 Exactly what I was about to suggest. Tim Delaney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
On Feb 26, 2011, at 02:05 PM, R. David Murray wrote: On Sat, 26 Feb 2011 13:08:47 -0500, Barry Warsaw ba...@python.org wrote: $ cd py27 # now I want to synchronize $ hg pull -u ssh://h...@hg.python.org/cpython but I'm not going to remember that url every time. It wouldn't be so bad if Mercurial remembered the pull URL for me, as (you guessed it :) Bazaar does. How does setting it in the hgrc differ from remebering it? 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. ;) I've never been comfortable with the bzr --remember option because I'm never sure what it is remembering. Much easier for me to see it in a config file. But, then, that's how my brain works, and other people's will work differently. It's easy to tell what it remembers because it's exactly what you told it to remember ;). But I guess you're talking about push and pull automatically remembering the location when none was previously set. I love that feature. And of course, bzr 'remembers' by setting a value in a config file, which of course you *could* hack if you wanted to. It's just that you don't normally have to open your editor and remember which value in which config file you have to manually modify to set the push and pull locations. I think that's a win, but YMMV. :) Oh, and 'bzr info' always tells you what the push and pull locations are. I find bazaar's model confusing, and hg's intuitive, just like Éric. And consider that I learned bazaar before mercurial. To me, it makes perfect sense that in a DVCS the unit is a directory containing a repository and a working copy, and that the repository is *the* repository. That is, it has everything related to the project in it, just like the master SVN repository does (plus, since it is a DVCS, whatever I've committed locally but not pushed to the master). To have a repository that only has some of the stuff in it is, IMO, confusing. I advocated for having all the Python history in one repo partly for that reason. I would feel better about Mercurial's if the repo where not intimately tied with a default working tree (yes, I know -U). In a sense, that's what Bazaar's shared repositories are: a place where all your history goes. In Bazaar's model though, it's not tied to a specific working tree, and it's hidden in a dot-directory. It's still kind of beside the point - this is the way Mercurial works, and I don't really mean this thread to be an in-depth comparison between the two. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
On Sat, 26 Feb 2011 16:06:45 -0500 Barry Warsaw ba...@python.org wrote: I find bazaar's model confusing, and hg's intuitive, just like Éric. And consider that I learned bazaar before mercurial. To me, it makes perfect sense that in a DVCS the unit is a directory containing a repository and a working copy, and that the repository is *the* repository. That is, it has everything related to the project in it, just like the master SVN repository does (plus, since it is a DVCS, whatever I've committed locally but not pushed to the master). To have a repository that only has some of the stuff in it is, IMO, confusing. I advocated for having all the Python history in one repo partly for that reason. I would feel better about Mercurial's if the repo where not intimately tied with a default working tree (yes, I know -U). In a sense, that's what Bazaar's shared repositories are: a place where all your history goes. In Bazaar's model though, it's not tied to a specific working tree, and it's hidden in a dot-directory. 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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
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 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 That's one way of doing it. 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. (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.) 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. 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. 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://h...@hg.python.org/cpython but I'm not going to remember that url every time. It wouldn't be so bad if Mercurial remembered the pull URL for me, as (you guessed it :) Bazaar does. So does Hg: simply edit your .hgrc to have it both pull and push to the same URL. Right, see my follow up to RDM. Or you can save yourself some trouble, and simply clone the repository at a specific branch: hg clone ssh://h...@hg.python.org/cpython#2.7 I believe that might even strip out other history outside the scope of the branch. That might be a better way if it doesn't slurp down the entire repository history. Anecdote: I migrated from Subversion to Mercurial a few years ago, and found Mercurial branches very intuitive. When I saw mentions of Bazaar branches I was driven nuts by (what I saw as) the conflation between a branch and a clone. Later I understood how it made sense from the perspective of Bazaar, so I shifted my judgment from “insanely confusing” to “a particular choice that I don’t approve” wink. That's funny because to my eyes, Mercurial conflates branches and clones. Why a clone operation should give me the history for all lines-of-development inside a working directory for one arbitrary one strikes me as bizarre (pardon the pun :). 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. Yep, I get all that. It's Mercurial's model of the world. 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. 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. :) 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.) 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. 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
Re: [Python-Dev] Mercurial conversion repositories
On Feb 26, 2011, at 10:20 PM, Antoine Pitrou 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 You sound like an iPhone commercial: There's an app for that. :) -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
On Sat, Feb 26, 2011 at 13:30, Barry Warsaw ba...@python.org wrote: 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 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 That's one way of doing it. 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. (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.) 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. 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. 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://h...@hg.python.org/cpython but I'm not going to remember that url every time. It wouldn't be so bad if Mercurial remembered the pull URL for me, as (you guessed it :) Bazaar does. So does Hg: simply edit your .hgrc to have it both pull and push to the same URL. Right, see my follow up to RDM. Or you can save yourself some trouble, and simply clone the repository at a specific branch: hg clone ssh://h...@hg.python.org/cpython#2.7 I believe that might even strip out other history outside the scope of the branch. That might be a better way if it doesn't slurp down the entire repository history. Anecdote: I migrated from Subversion to Mercurial a few years ago, and found Mercurial branches very intuitive. When I saw mentions of Bazaar branches I was driven nuts by (what I saw as) the conflation between a branch and a clone. Later I understood how it made sense from the perspective of Bazaar, so I shifted my judgment from “insanely confusing” to “a particular choice that I don’t approve” wink. That's funny because to my eyes, Mercurial conflates branches and clones. Why a clone operation should give me the history for all lines-of-development inside a working directory for one arbitrary one strikes me as bizarre (pardon the pun :). 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. Yep, I get all that. It's Mercurial's model of the world. 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. 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. :) 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.) 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. Not single, _current_. I
Re: [Python-Dev] Mercurial conversion repositories
On Sat, Feb 26, 2011 at 3:09 PM, Brett Cannon br...@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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
On 2011-02-26 22:06, Barry Warsaw wrote: On Feb 26, 2011, at 02:05 PM, R. David Murray wrote: On Sat, 26 Feb 2011 13:08:47 -0500, Barry Warsaw ba...@python.org wrote: $ cd py27 # now I want to synchronize $ hg pull -u ssh://h...@hg.python.org/cpython but I'm not going to remember that url every time. It wouldn't be so bad if Mercurial remembered the pull URL for me, as (you guessed it :) Bazaar does. How does setting it in the hgrc differ from remebering it? It's different because you don't use a familiar interface to set it (i.e hg). You have to know to hack a file to make it work. That's not awesome user interface. ;) You'd have to take this up with Mercurial's BDFL Matt. He is a strong advocate for teaching users to learn edit their .hg/hgrc files. And he's quite firm on not wanting to have Mercurial touch .hg/hgrc -- with the single exception being to write a initial .hg/hgrc on 'hg clone', containing the default path with the location from where the repo was cloned. Regarding Bazaar: FWIW, I periodically retried the speed of 'bzr check' - and always gave up again looking at bzr due to the horrible slowness of that command. If I have to use a DVCS I want to be able to check the integrity of my clones in reasonable time. I do it with a cron job on our internal server here and I expect it to have finished checking all our repos when I get to my desk in the morning and look into my email inbox, reading the daily email with the result of the verify runs. After all, we do have everything secured with hashes, so we can use them, don't we? I've never been comfortable with the bzr --remember option because I'm never sure what it is remembering. Much easier for me to see it in a config file. But, then, that's how my brain works, and other people's will work differently. It's easy to tell what it remembers because it's exactly what you told it to remember ;). But I guess you're talking about push and pull automatically remembering the location when none was previously set. I love that feature. And of course, bzr 'remembers' by setting a value in a config file, which of course you *could* hack if you wanted to. It's just that you don't normally have to open your editor and remember which value in which config file you have to manually modify to set the push and pull locations. I think that's a win, but YMMV. :) Oh, and 'bzr info' always tells you what the push and pull locations are. You can use 'hg paths' for that: See http://selenic.com/repo/hg/help/paths or 'hg help paths' on the command line. I find bazaar's model confusing, and hg's intuitive, just like Éric. And consider that I learned bazaar before mercurial. To me, it makes perfect sense that in a DVCS the unit is a directory containing a repository and a working copy, and that the repository is *the* repository. That is, it has everything related to the project in it, just like the master SVN repository does (plus, since it is a DVCS, whatever I've committed locally but not pushed to the master). To have a repository that only has some of the stuff in it is, IMO, confusing. I advocated for having all the Python history in one repo partly for that reason. I would feel better about Mercurial's if the repo where not intimately tied with a default working tree (yes, I know -U). In a sense, that's what Bazaar's shared repositories are: a place where all your history goes. In Bazaar's model though, it's not tied to a specific working tree, and it's hidden in a dot-directory. It's still kind of beside the point - this is the way Mercurial works, and I don't really mean this thread to be an in-depth comparison between the two. I'm quite surprised indeed to read that much about Bazaar in this thread here :) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
On Sat, Feb 26, 2011 at 1:37 PM, Brett Cannon br...@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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
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. :) 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? 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 signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
On 2011-02-27 01:50, Barry Warsaw wrote: 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. :) Yep. 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? Do you know how thorough 'bzr check' is? I don't, but then I've never used it or felt the need to. ;) 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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
changeset: 72694:e65daae6cf44 user:Antoine Pitrou solip...@pitrou.net date:Mon Feb 21 21:30:55 2011 + summary: Try s/UINT_MAX/INT_MAX/ 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). 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 solip...@pitrou.net date:Mon Feb 21 21:25:39 2011 + 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. 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). 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. 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). 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). 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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
On Fri, Feb 25, 2011 at 09:09, Martin v. Löwis mar...@v.loewis.de wrote: 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). Unnamed heads are trivial to convert to clones. Cheers, Dirkjan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
Am 25.02.2011 09:17, schrieb Dirkjan Ochtman: On Fri, Feb 25, 2011 at 09:09, Martin v. Löwis mar...@v.loewis.de wrote: 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). Unnamed heads are trivial to convert to clones. If there are hundreds of them, it's far from trivial. I don't even know how to find out which one to convert. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
On Fri, Feb 25, 2011 at 09:25, Martin v. Löwis mar...@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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
Am 25.02.2011 09:29, schrieb Dirkjan Ochtman: On Fri, Feb 25, 2011 at 09:25, Martin v. Löwis mar...@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). Ah ok. So I guess that goes back to my original request - that the PEP be updated. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
On Feb 25, 2011, at 12:09 AM, Martin v. Löwis wrote: 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). In my brief tests, the single repository has been easy to work with. If they were separate, it would complicate backporting patches and merges. So, I'm happy with how George and Benjamin put this together. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
On Fri, 25 Feb 2011 19:13:49 +1100 Neil Hodgson nyamaton...@gmail.com wrote: 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. 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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
On Thu, 24 Feb 2011 17:39:40 -0800 Brett Cannon br...@python.org wrote: Your clone will contain the following branches: $ hg branches default68026:f12ef116dd10 3.268025:cef92ee1a323 2.768010:8174d00d0797 3.167955:5be8b695ea86 2.667287:5e26a860eded 2.565464:e4ecac76e499 trunk 62750:800f6c92c3ed 3.060075:1d05144224fe 2.458552:df72cac1899e 2.345731:a3d9a9730743 2.240444:d55ddc8c8501 2.130171:06fcccf6eca8 2.018214: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. Just to help justify it in my head, the trunk branch exists for the history and nothing more, right? 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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
On 25.02.2011 09:25, Martin v. Löwis wrote: Am 25.02.2011 09:17, schrieb Dirkjan Ochtman: On Fri, Feb 25, 2011 at 09:09, Martin v. Löwis mar...@v.loewis.de wrote: 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). Unnamed heads are trivial to convert to clones. If there are hundreds of them, it's far from trivial. I don't even know how to find out which one to convert. 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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
On Feb 25, 2011, at 01:50 AM, Raymond Hettinger wrote: On Feb 25, 2011, at 12:09 AM, Martin v. Löwis wrote: 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). In my brief tests, the single repository has been easy to work with. If they were separate, it would complicate backporting patches and merges. So, I'm happy with how George and Benjamin put this together. 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 signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
Hi Barry, 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. 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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
On 25.02.2011 17:12, Barry Warsaw wrote: On Feb 25, 2011, at 01:50 AM, Raymond Hettinger wrote: On Feb 25, 2011, at 12:09 AM, Martin v. Löwis wrote: 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). In my brief tests, the single repository has been easy to work with. If they were separate, it would complicate backporting patches and merges. So, I'm happy with how George and Benjamin put this together. 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. 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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
On 25.02.2011 17:31, Georg Brandl wrote: On 25.02.2011 17:12, Barry Warsaw wrote: On Feb 25, 2011, at 01:50 AM, Raymond Hettinger wrote: On Feb 25, 2011, at 12:09 AM, Martin v. Löwis wrote: 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). In my brief tests, the single repository has been easy to work with. If they were separate, it would complicate backporting patches and merges. So, I'm happy with how George and Benjamin put this together. 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. 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. Ah, and the latter obviously also won't work with the hg-native workflow (merging between the branches using hg merge). Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
On Fri, 25 Feb 2011 13:52:58 +0100 Antoine Pitrou solip...@pitrou.net wrote: On Fri, 25 Feb 2011 19:13:49 +1100 Neil Hodgson nyamaton...@gmail.com wrote: 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. 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. 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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
On 2011-02-25 17:12, Barry Warsaw wrote: On Feb 25, 2011, at 01:50 AM, Raymond Hettinger wrote: On Feb 25, 2011, at 12:09 AM, Martin v. Löwis wrote: 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). In my brief tests, the single repository has been easy to work with. If they were separate, it would complicate backporting patches and merges. So, I'm happy with how George and Benjamin put this together. 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?). 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://h...@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://h...@hg.python.org/cpython instead, you'd want to edit the [paths] section in the .hg/hgrc file in each of the branch repos. 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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
On Feb 25, 2011, at 06:40 PM, Adrian Buehlmann wrote: First, get an initial clone (let's name it 'master') over the wire using: [1] $ hg clone -U ssh://h...@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 Note that each of these branch clones will initially have your local master repo as the default path [3,4]. If you'd like to have the default push/pull path to point to ssh://h...@hg.python.org/cpython instead, you'd want to edit the [paths] section in the .hg/hgrc file in each of the branch repos. 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 signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
On Fri, 25 Feb 2011 14:43:15 -0500 Barry Warsaw ba...@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). 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? Should be customizable: http://mercurial.selenic.com/wiki/CommitMessageTemplate http://mercurial.selenic.com/wiki/DiffsInCommitMessageInVIM (never tried myself) Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
On 25/02/2011 20:43, Barry Warsaw wrote: 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? 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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
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\cpythonhg push pushing to http://hg.python.org/cpython searching for changes remote: ssl required Neil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
Le samedi 26 février 2011 à 08:40 +1100, Neil Hodgson a écrit : 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: Ok, well that's expected then ;) Sorry for the confusion. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
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 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. You mean, TortoiseHg supports incremental commits on a single file? That's kind of neat, but scary. ;) -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
On 25Feb2011 14:43, Barry Warsaw ba...@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 c...@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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
Hi, Le 25/02/2011 20:43, Barry Warsaw a écrit : On Feb 25, 2011, at 06:40 PM, Adrian Buehlmann wrote: [snip] Note that each of these branch clones will initially have your local master repo as the default path [3,4]. If you'd like to have the default push/pull path to point to ssh://h...@hg.python.org/cpython instead, you'd want to edit the [paths] section in the .hg/hgrc file in each of the branch repos. I plan on having one clone per branch but pushing and pulling from only one repository, so I don’t need to edit hgrcs. It does leave me with an empty 'master' directory that I basically won't touch, though I suppose I could hide it in a dot-filename. Or have the master clone do double duty as the py3k clone. (IOW, I have 2.7 3.1 3.2 py3k, I pull/push in py3k and also do merges and new features in py3k). And I have to remember to fiddle with .hg/hgrc when I clone a new branch working directory, but I guess that's mostly a one-time cost. You don’t, see above. I’ve wanted to tell you something for a long time: Mercurial branches are not at all like Bazaar branches. See http://mercurial.selenic.com/wiki/Branch and http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/ Anecdote: I migrated from Subversion to Mercurial a few years ago, and found Mercurial branches very intuitive. When I saw mentions of Bazaar branches I was driven nuts by (what I saw as) the conflation between a branch and a clone. Later I understood how it made sense from the perspective of Bazaar, so I shifted my judgment from “insanely confusing” to “a particular choice that I don’t approve” wink. What I’m saying is that a lot of Bazaar terminology using “branch” does not map as-is to Mercurial. We clone a repo, we pull from a repo/clone, we have named branches (e.g. 3.2) in a repo, we have unnamed branches on one named branch. I think you know that already, since you went from using Bazaar terms applied to Mercurial to mixing terms from both (“clone a new branch working directory” → “clone a repo”, probably). I salute your willingness to learn Mercurial, considering how fluent (and fluffly) you appear to be with Bazaar. I'll have to remember that 'hg pull' does not update the working copy by default, That pull does not update is a feature: The operation between a remote repo and the local repo (the .hg directory) is separate from the operation from the local repo to the working directory. When you know that you want pull + update (like when you have a clean working directory), you use “hg pull -u”. (I don’t like the fetch command.) and eventually I'll figure out the whole merge thing. Without anything specific, I’ll point to some resources: Short tuto: http://hginit.com/04.html Concepts and examples: http://mercurial.selenic.com/wiki/Merge Longer narratives: http://hgbook.red-bean.com/read/a-tour-of-mercurial-merging-work.html http://hgbook.red-bean.com/read/managing-releases-and-branchy-development.html One immediate thing that I'm missing from Bazaar is that 'bzr commit' invokes my editor and always shows me a 'diff -u' in the commit message buffer. This is incredibly handy because I don't have to remember to do the diff in a different window, and I always have all the information I want right there to craft the commit message. You speak to my heart, sir. In your ~/.hgrc, under the section [ui], set “editor = path/to/mercurial/source/hgeditor” and enjoy your diffs. I use it and love it. If you want to commit a subset of your local changes, I use http://mercurial.selenic.com/wiki/CrecordExtension , a curses-based diff selection UI that works like a charm. Kind regards, your friendly Mercurial whippersnapper ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
On Fri, Feb 25, 2011 at 10:19 AM, Antoine Pitrou solip...@pitrou.net wrote: $ 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. 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 | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
On Sat, 26 Feb 2011 12:32:04 +1000 Nick Coghlan ncogh...@gmail.com wrote: On Fri, Feb 25, 2011 at 10:19 AM, Antoine Pitrou solip...@pitrou.net wrote: $ 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. 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. 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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
On 26.02.2011 03:32, Nick Coghlan wrote: On Fri, Feb 25, 2011 at 10:19 AM, Antoine Pitrou solip...@pitrou.net wrote: $ hg branches default68026:f12ef116dd10 3.268025:cef92ee1a323 2.768010:8174d00d0797 3.167955:5be8b695ea86 2.667287:5e26a860eded 2.565464:e4ecac76e499 trunk 62750:800f6c92c3ed 3.060075:1d05144224fe 2.458552:df72cac1899e 2.345731:a3d9a9730743 2.240444:d55ddc8c8501 2.130171:06fcccf6eca8 2.018214: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. 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. Problem is, you then have 1.5.2 released from the 2.x branch :) Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
On Feb 24, 2011, at 4:19 PM, Antoine Pitrou wrote: 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/ Thank you both for all the effort you put in. I'll do some tests today. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
On Thu, Feb 24, 2011 at 16:19, Antoine Pitrou solip...@pitrou.net wrote: Hello, Georg and I have been working on converting the SVN repository to Mercurial. We can now present you a test repository (actually, two). Thanks to the both of you for moving this forward! 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://h...@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 default68026:f12ef116dd10 3.268025:cef92ee1a323 2.768010:8174d00d0797 3.167955:5be8b695ea86 2.667287:5e26a860eded 2.565464:e4ecac76e499 trunk 62750:800f6c92c3ed 3.060075:1d05144224fe 2.458552:df72cac1899e 2.345731:a3d9a9730743 2.240444:d55ddc8c8501 2.130171:06fcccf6eca8 2.018214: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. 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 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). 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 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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
On Fri, Feb 25, 2011 at 02:19, Antoine Pitrou solip...@pitrou.net wrote: 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://h...@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 ) Yay - Mercurial at last! Thanks for pushing this forward. I'll do some tests with the new repo later today. Eli ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
On 25.02.2011 01:19, Antoine Pitrou wrote: Hello, Georg and I have been working on converting the SVN repository to Mercurial. We can now present you a test repository (actually, two). 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. 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://h...@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 ) [...] 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. 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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mercurial conversion repositories
On Fri, Feb 25, 2011 at 01:19, Antoine Pitrou solip...@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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
