Re: [Python-Dev] PEP 374 (DVCS) now in reST
a Mercurial super client http://blog.red-bean.com/sussman/?p=116 Figured I would link to this for the people doing the HG investigation ___ 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] PEP 374 (DVCS) now in reST
On Mon, Jan 26, 2009 at 1:38 PM, Stephen J. Turnbull step...@xemacs.org wrote: Again, I don't take the cost of learning a new tool lightly, but please let's call that cost by its name, and not bring distributed into it. I can only strongly agree on this point - most people asserting that DVCS are much more complicated than CVS/SVN/etc..., forget their long experience with the later. I had little experience with svn before using bzr, and I find bzr much simpler than svn in almost every way, both for personal projects and more significant open source projects. That's false. Again, those people who want to use a DVCS as a DVCS will benefit from having the master repository(s) coordinate history for them. This doesn't work very well across VCS systems, essentially forcing all committers who want to use the distributed features to coordinate with each other directly, and only with those who use the same DVCS. The mental models used by git users, hg users, and bzr users differ significantly, though they probably differ more from the model that's appropriate for Subversion. Nevertheless, there is a lot of potential benefit to be gained from having a common DVCS for all developers. Agreed. A point shared by all svn-to-bzr/git/whatever in my experience is the pain of merging. In particular, although git-svn on top of svn is very useful, and brings some power of git without forcing git pain on other users, merging between branches is not really doable without going back to svn. And that's certainly a big plus of DVCS compared to svn: since svn is inherently incapable of tracking merge (at least until recently, I have no experience with 1.5), you can't use svn as a backend and benefeting from all the DVCS advantages at the same time. cheers, David ___ 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] PEP 374 (DVCS) now in reST
On Mon, 26 Jan 2009 10:31:55 -0800, Guido van Rossum wrote: On Mon, Jan 26, 2009 at 8:08 AM, Paul Hummer p...@eventuallyanyway.com wrote: At a previous employer, we had this same discussion about switching to a DVCS, and the time and cost required to learn the new tool. We switched to bzr, and while there were days where someone got lost in the DVCS, the overall advantages with merging allowed that cost to be offset by the fact that merging was so cheap (and we merged a lot). That's a big consideration to be made when you're considering a DVCS. Merges in SVN and CVS can be painful, where merging well is a core feature of any DVCS. I hear you. I for one have been frustrated (now that you mention it) by the inability to track changes across merges. We do lots of merges from the trunk into the py3k branch, and the merge revisions in the branch quotes the full text of the changes merged from the trunk, but not the list of affected files for each revision merged. Since merges typically combine a lot of revisions, it is very painful to find out more about a particular change to a file when that change came from such a merge -- often even after reading through the entire list of descriptions you still have no idea which merged revision is responsible for a particular change. Assuming this problem does not exist in DVCS, that would be a huge bonus from switching to a DVCS! Well, not only it does not exist by design in any DVCS, but I have a better news: it does not exist anymore in Subversion 1.5. You just need to upgrade your SVN server to 1.5, migrate your merge history from the format of svnmerge to the new builtin format (using the official script), and you're done: say hello to -g/--use-merge-history, to be use with svn log and svn blame. This is a good writeup of the new features: http://chestofbooks.com/computers/revision-control/subversion-svn/Merge- Sensitive-Logs-And-Annotations-Branchmerge-Advanced-Lo.html -- Giovanni Bajo Develer S.r.l. http://www.develer.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] PEP 374 (DVCS) now in reST
On Mon, Jan 26, 2009 at 1:57 PM, Giovanni Bajo ra...@develer.com wrote: On Mon, 26 Jan 2009 10:31:55 -0800, Guido van Rossum wrote: On Mon, Jan 26, 2009 at 8:08 AM, Paul Hummer p...@eventuallyanyway.com wrote: At a previous employer, we had this same discussion about switching to a DVCS, and the time and cost required to learn the new tool. We switched to bzr, and while there were days where someone got lost in the DVCS, the overall advantages with merging allowed that cost to be offset by the fact that merging was so cheap (and we merged a lot). That's a big consideration to be made when you're considering a DVCS. Merges in SVN and CVS can be painful, where merging well is a core feature of any DVCS. I hear you. I for one have been frustrated (now that you mention it) by the inability to track changes across merges. We do lots of merges from the trunk into the py3k branch, and the merge revisions in the branch quotes the full text of the changes merged from the trunk, but not the list of affected files for each revision merged. Since merges typically combine a lot of revisions, it is very painful to find out more about a particular change to a file when that change came from such a merge -- often even after reading through the entire list of descriptions you still have no idea which merged revision is responsible for a particular change. Assuming this problem does not exist in DVCS, that would be a huge bonus from switching to a DVCS! Well, not only it does not exist by design in any DVCS, but I have a better news: it does not exist anymore in Subversion 1.5. You just need to upgrade your SVN server to 1.5, migrate your merge history from the format of svnmerge to the new builtin format (using the official script), and you're done: say hello to -g/--use-merge-history, to be use with svn log and svn blame. This is a good writeup of the new features: http://chestofbooks.com/computers/revision-control/subversion-svn/Merge- Sensitive-Logs-And-Annotations-Branchmerge-Advanced-Lo.html Unfortunately I've heard we shouldn't upgrade to svn 1.5 until more Linux distributions ship with it by default. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] PEP 374 (DVCS) now in reST
On Mon, Jan 26, 2009 at 2:00 PM, Guido van Rossum gu...@python.org wrote: On Mon, Jan 26, 2009 at 1:57 PM, Giovanni Bajo ra...@develer.com wrote: On Mon, 26 Jan 2009 10:31:55 -0800, Guido van Rossum wrote: On Mon, Jan 26, 2009 at 8:08 AM, Paul Hummer p...@eventuallyanyway.com wrote: At a previous employer, we had this same discussion about switching to a DVCS, and the time and cost required to learn the new tool. We switched to bzr, and while there were days where someone got lost in the DVCS, the overall advantages with merging allowed that cost to be offset by the fact that merging was so cheap (and we merged a lot). That's a big consideration to be made when you're considering a DVCS. Merges in SVN and CVS can be painful, where merging well is a core feature of any DVCS. I hear you. I for one have been frustrated (now that you mention it) by the inability to track changes across merges. We do lots of merges from the trunk into the py3k branch, and the merge revisions in the branch quotes the full text of the changes merged from the trunk, but not the list of affected files for each revision merged. Since merges typically combine a lot of revisions, it is very painful to find out more about a particular change to a file when that change came from such a merge -- often even after reading through the entire list of descriptions you still have no idea which merged revision is responsible for a particular change. Assuming this problem does not exist in DVCS, that would be a huge bonus from switching to a DVCS! Well, not only it does not exist by design in any DVCS, but I have a better news: it does not exist anymore in Subversion 1.5. You just need to upgrade your SVN server to 1.5, migrate your merge history from the format of svnmerge to the new builtin format (using the official script), and you're done: say hello to -g/--use-merge-history, to be use with svn log and svn blame. This is a good writeup of the new features: http://chestofbooks.com/computers/revision-control/subversion-svn/Merge- Sensitive-Logs-And-Annotations-Branchmerge-Advanced-Lo.html Unfortunately I've heard we shouldn't upgrade to svn 1.5 until more Linux distributions ship with it by default. Besides that, `svn merge` cannot handle parallel branches like trunk/py3k without lots of handholding. Unlike svnmerge.py, when you merge to and then from a branch, it tries to merge changes that came from trunk and produces lots of conflicts. (Before you point me at --reintegrate, note In Subversion 1.5, once a --reintegrate merge is done from branch to trunk, the branch is no longer usable for further work. from the book.) In principle, the svn devs could fix this, but they didn't in svn 1.5. To keep this slighly on topic ... maybe the abilities and limits of svnmerge.py and `svn merge` should be mentioned in the PEP? ___ 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] PEP 374 (DVCS) now in reST
On Jan 26, 2009, at 5:18 PM, Jeffrey Yasskin jyass...@gmail.com wrote: On Mon, Jan 26, 2009 at 2:00 PM, Guido van Rossum gu...@python.org wrote: On Mon, Jan 26, 2009 at 1:57 PM, Giovanni Bajo ra...@develer.com wrote: On Mon, 26 Jan 2009 10:31:55 -0800, Guido van Rossum wrote: On Mon, Jan 26, 2009 at 8:08 AM, Paul Hummer p...@eventuallyanyway.com wrote: At a previous employer, we had this same discussion about switching to a DVCS, and the time and cost required to learn the new tool. We switched to bzr, and while there were days where someone got lost in the DVCS, the overall advantages with merging allowed that cost to be offset by the fact that merging was so cheap (and we merged a lot). That's a big consideration to be made when you're considering a DVCS. Merges in SVN and CVS can be painful, where merging well is a core feature of any DVCS. I hear you. I for one have been frustrated (now that you mention it) by the inability to track changes across merges. We do lots of merges from the trunk into the py3k branch, and the merge revisions in the branch quotes the full text of the changes merged from the trunk, but not the list of affected files for each revision merged. Since merges typically combine a lot of revisions, it is very painful to find out more about a particular change to a file when that change came from such a merge -- often even after reading through the entire list of descriptions you still have no idea which merged revision is responsible for a particular change. Assuming this problem does not exist in DVCS, that would be a huge bonus from switching to a DVCS! Well, not only it does not exist by design in any DVCS, but I have a better news: it does not exist anymore in Subversion 1.5. You just need to upgrade your SVN server to 1.5, migrate your merge history from the format of svnmerge to the new builtin format (using the official script), and you're done: say hello to -g/--use-merge-history, to be use with svn log and svn blame. This is a good writeup of the new features: http://chestofbooks.com/computers/revision-control/subversion-svn/Merge- Sensitive-Logs-And-Annotations-Branchmerge-Advanced-Lo.html Unfortunately I've heard we shouldn't upgrade to svn 1.5 until more Linux distributions ship with it by default. Besides that, `svn merge` cannot handle parallel branches like trunk/py3k without lots of handholding. Unlike svnmerge.py, when you merge to and then from a branch, it tries to merge changes that came from trunk and produces lots of conflicts. (Before you point me at --reintegrate, note In Subversion 1.5, once a --reintegrate merge is done from branch to trunk, the branch is no longer usable for further work. from the book.) In principle, the svn devs could fix this, but they didn't in svn 1.5. To keep this slighly on topic ... maybe the abilities and limits of svnmerge.py and `svn merge` should be mentioned in the PEP? Everytime I merge with subversion, it makes me appreciate perforce's branching and merging that much more. Jesse ___ 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] PEP 374 (DVCS) now in reST
Unfortunately I've heard we shouldn't upgrade to svn 1.5 until more Linux distributions ship with it by default. We *could* upgrade to subversion 1.5 on the server (if only Debian would get their ... together and release the version they promised for last September). The question is then whether we would drop svnmerge, in favour of the 1.5 merge tracking. IIUC, that would require all committers to use 1.5 - I'm not sure whether this poses a challenge to any committer. 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] PEP 374 (DVCS) now in reST
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 25, 2009, at 10:27 PM, Jared Grubb wrote: Regardless of the outcome, those that want to use SVN can use SVN, and those that want to use chosen DVCS can use that. In the end, which is the more lossy repository? It seems like if the change is transparent to everyone who is using it, then the only thing that we care about is that the chosen backend will preserve all the information to make it truly transparent to everyone involved. svn is the more lossy repository format. Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSX5vZnEjvBPtnXfVAQJzcgP/SweUwXoECPJpO5BEkmdTLDoEfPP1X1Lg m4AALSFZ3cfRUPX3UgGmT7anY604o5oaElFR8b0HkIScJvhF56nzs9oAR0Yqi8jN zThG1rizDHh+RSqUZ0yXKHVF6ScNf8aRg/cLoVtV+J6KGpYtTCSGTQWGnvSQxCj9 I+BY75DHOI8= =9A3a -END 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] PEP 374 (DVCS) now in reST
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 24, 2009, at 7:48 PM, Brett Cannon wrote: As part of my impressions I plan to also look at usage on top of svn as a viable alternative if no clear winner comes about. That way if they work well directly on top of svn we can write up very clear documentation on how to use any of them directly on top of svn and still gain the benefits of offline checkins and cheap branching. Maintenance then becomes simply keeping a read-only mirror going on code.python.org. There's a possible third way. I've heard (though haven't investigated) that some people are working on supporting the svn wire protocol in the bzr server. This would mean that anybody who's still comfortable with svn and feels no need to change their current habits can continue to work the way they always have. Those that want the extra benefits of a DVCS, or who do not have commit access to the code.python.org branches would have viable alternatives. Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSXx8tHEjvBPtnXfVAQK1CgQAoDlHr9KthVr9sA6DfeXE3D35mYUop01X TD06OggbayFDGQYA0Zae+zU050R9UvuTpaF7XtSiSgBlI6n0Bb/rLAgVGskwbMHD LU8BAljNq6FpRp8QY2IHVRWKgOqzSHtz8CvCdlD1yw5CbA/pEvigoLzR0AWAeQJl tzOAetiud2c= =5qIJ -END 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] PEP 374 (DVCS) now in reST
There's a possible third way. I've heard (though haven't investigated) that some people are working on supporting the svn wire protocol in the bzr server. This would mean that anybody who's still comfortable with svn and feels no need to change their current habits can continue to work the way they always have. Those that want the extra benefits of a DVCS, or who do not have commit access to the code.python.org branches would have viable alternatives. Of course, those without commit access *already* have viable alternatives, IIUC, by means of the automatic ongoing conversion of the svn repository to bzr and hg (and, IIUC, git - or perhaps you can use git-svn without the need for server-side conversion). So a conversion to a DVCS would only benefit those committers who see a benefit in using a DVCS (*) (and would put a burden on those committers who see a DVCS as a burden). It would also put a burden on contributors who are uncomfortable with using a DVCS. Regards, Martin (*) I'm probably missing something, but ISTM that committers can already use the DVCS - they only need to create a patch just before committing. This, of course, is somewhat more complicated than directly pushing the changes to the server, but it still gives them most of what is often reported as the advantage of a DVCS (local commits, ability to have many branches simultaneously, ability to share work-in-progress, etc). In essence, committers wanting to use a DVCS can do so today, by acting as if they were non-committers, and only using svn for actual changes to the master repository. ___ 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] PEP 374 (DVCS) now in reST
Martin v. Löwis martin at v.loewis.de writes: In essence, committers wanting to use a DVCS can do so today, by acting as if they were non-committers, and only using svn for actual changes to the master repository. Indeed. It is how I work. 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] PEP 374 (DVCS) now in reST
Brett Cannon wrote: On Sun, Jan 25, 2009 at 10:37, Martin v. Löwis mar...@v.loewis.de wrote: There's a possible third way. I've heard (though haven't investigated) that some people are working on supporting the svn wire protocol in the bzr server. This would mean that anybody who's still comfortable with svn and feels no need to change their current habits can continue to work the way they always have. Those that want the extra benefits of a DVCS, or who do not have commit access to the code.python.org branches would have viable alternatives. Of course, those without commit access *already* have viable alternatives, IIUC, by means of the automatic ongoing conversion of the svn repository to bzr and hg (and, IIUC, git - or perhaps you can use git-svn without the need for server-side conversion). So a conversion to a DVCS would only benefit those committers who see a benefit in using a DVCS (*) (and would put a burden on those committers who see a DVCS as a burden). It would also put a burden on contributors who are uncomfortable with using a DVCS. Regards, Martin (*) I'm probably missing something, but ISTM that committers can already use the DVCS - they only need to create a patch just before committing. This, of course, is somewhat more complicated than directly pushing the changes to the server, but it still gives them most of what is often reported as the advantage of a DVCS (local commits, ability to have many branches simultaneously, ability to share work-in-progress, etc). In essence, committers wanting to use a DVCS can do so today, by acting as if they were non-committers, and only using svn for actual changes to the master repository. If I can't choose a clear winner I am going to look into what it take to run directly on top of svn to avoid the extra step for committers. Otherwise I will get standardized instructions for the three DVCSs and maybe write a script or three to make it dead-simple to work with the DVCSs but have our official repository be svn so we can all use the DVCSs as we see fit until a clear winner springs up. Well, that sounds like an ideal situation to end up in. Is there a downside other than the work it creates for you? Michael -Brett ___ 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.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ 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] PEP 374 (DVCS) now in reST
On Sun, Jan 25, 2009 at 13:03, Michael Foord fuzzy...@voidspace.org.uk wrote: Brett Cannon wrote: On Sun, Jan 25, 2009 at 10:37, Martin v. Löwis mar...@v.loewis.de wrote: There's a possible third way. I've heard (though haven't investigated) that some people are working on supporting the svn wire protocol in the bzr server. This would mean that anybody who's still comfortable with svn and feels no need to change their current habits can continue to work the way they always have. Those that want the extra benefits of a DVCS, or who do not have commit access to the code.python.org branches would have viable alternatives. Of course, those without commit access *already* have viable alternatives, IIUC, by means of the automatic ongoing conversion of the svn repository to bzr and hg (and, IIUC, git - or perhaps you can use git-svn without the need for server-side conversion). So a conversion to a DVCS would only benefit those committers who see a benefit in using a DVCS (*) (and would put a burden on those committers who see a DVCS as a burden). It would also put a burden on contributors who are uncomfortable with using a DVCS. Regards, Martin (*) I'm probably missing something, but ISTM that committers can already use the DVCS - they only need to create a patch just before committing. This, of course, is somewhat more complicated than directly pushing the changes to the server, but it still gives them most of what is often reported as the advantage of a DVCS (local commits, ability to have many branches simultaneously, ability to share work-in-progress, etc). In essence, committers wanting to use a DVCS can do so today, by acting as if they were non-committers, and only using svn for actual changes to the master repository. If I can't choose a clear winner I am going to look into what it take to run directly on top of svn to avoid the extra step for committers. Otherwise I will get standardized instructions for the three DVCSs and maybe write a script or three to make it dead-simple to work with the DVCSs but have our official repository be svn so we can all use the DVCSs as we see fit until a clear winner springs up. Well, that sounds like an ideal situation to end up in. Is there a downside other than the work it creates for you? What, isn't creating even more work from me enough of a downside? =) There is also the issue of support. If we as a development team start using four different VCSs then that will severely cut down on who can help whom. The only reason I have been able to keep the dev FAQ full of such key svn commands is because inevitably someone on this list knew how to do something if I didn't. Spread that across three more DVCSs and the chances of someone knowing the best solution for something dwindles. It also means three more VCSs to keep up and running on code.python.org. While it has worked so far, that's just because we have been going with what Debian stable has. If you want some new-fangled thing, e.g. bzr's 1.9 tree support which apparently makes a huge performance difference (Barry is on vacation but I am prodding him to put the details in the PEP when he gets back) someone will then need to step up that we trust to stay on top of security patches, etc. So yes, it's a nice solution if a winner cannot be chosen, but I don't think that should necessarily be the end of this quite yet. -Brett ___ 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] PEP 374 (DVCS) now in reST
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 25, 2009, at 1:37 PM, Martin v. Löwis wrote: (*) I'm probably missing something, but ISTM that committers can already use the DVCS - they only need to create a patch just before committing. This, of course, is somewhat more complicated than directly pushing the changes to the server, but it still gives them most of what is often reported as the advantage of a DVCS (local commits, ability to have many branches simultaneously, ability to share work-in-progress, etc). In essence, committers wanting to use a DVCS can do so today, by acting as if they were non-committers, and only using svn for actual changes to the master repository. The approach you outline also has the disadvantages of losing history at the point of patch generation, and causing a discontinuity in the chain of revisions leading up to that point. Depending on the specific changes being merged, this may or may not be important. You're right that we can do this today, but I still believe there are advantages to supporting a DVCS for the official branches. Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSXzkjnEjvBPtnXfVAQIUOAP/SLkPAkIqDKNpoIpbaCJTsoLwFsSKj58P ISKqF7QkMgjl+cnw4YngHHwJr+OniX4cR1Wc5S9LPB3xMgsoOtxqYWmvfG1ReJRs fbmI1iOOCmOY1MltRlPErihS3wk7+37pc4lIkEvClvZMRcoLq3JjborIQjiy0ORY pqmovGlx/AI= =wXVD -END 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] PEP 374 (DVCS) now in reST
Regardless of the outcome, those that want to use SVN can use SVN, and those that want to use chosen DVCS can use that. In the end, which is the more lossy repository? It seems like if the change is transparent to everyone who is using it, then the only thing that we care about is that the chosen backend will preserve all the information to make it truly transparent to everyone involved. Jared On 25 Jan 2009, at 10:37, Martin v. Löwis wrote: There's a possible third way. I've heard (though haven't investigated) that some people are working on supporting the svn wire protocol in the bzr server. This would mean that anybody who's still comfortable with svn and feels no need to change their current habits can continue to work the way they always have. Those that want the extra benefits of a DVCS, or who do not have commit access to the code.python.org branches would have viable alternatives. Of course, those without commit access *already* have viable alternatives, IIUC, by means of the automatic ongoing conversion of the svn repository to bzr and hg (and, IIUC, git - or perhaps you can use git-svn without the need for server-side conversion). So a conversion to a DVCS would only benefit those committers who see a benefit in using a DVCS (*) (and would put a burden on those committers who see a DVCS as a burden). It would also put a burden on contributors who are uncomfortable with using a DVCS. Regards, Martin (*) I'm probably missing something, but ISTM that committers can already use the DVCS - they only need to create a patch just before committing. This, of course, is somewhat more complicated than directly pushing the changes to the server, but it still gives them most of what is often reported as the advantage of a DVCS (local commits, ability to have many branches simultaneously, ability to share work-in-progress, etc). In essence, committers wanting to use a DVCS can do so today, by acting as if they were non-committers, and only using svn for actual changes to the master repository. ___ 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/jared.grubb%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] PEP 374 (DVCS) now in reST
Martin v. Löwis writes: So a conversion to a DVCS would only benefit those committers who see a benefit in using a DVCS (*) (and would put a burden on those committers who see a DVCS as a burden). That's false. Especially with bzr, they would see improved log formats by default, and with git they'd have access to some very advanced and powerful history querying, even if the update-hack- commit side of the workflow doesn't change. Not having used these tools in most cases, the fact that they don't currently *perceive* a benefit from switching doesn't mean there won't be one. There's also the very high likelihood that if Python does switch to a DVCS, many such committers will start to use the distributed VCS features actively. That doesn't mean that it will fully offset the costs of the switch for them; it does mean that the net cost of the switch for them is probably a lot lower than it would appear from your description. It would also put a burden on contributors who are uncomfortable with using a DVCS. Discomfort is not something I take lightly, but I have to wonder how long that discomfort would persist. All of the DVCSes support exactly the same workflow as CVS/Subversion, with some change in naming, and possibly a need to have a trivial commit+push script to give a single command with the semantics of svn commit. This is crystal clear if you look at the draft PEP 374, which deliberately emulates the Subversion workflow in a variety of scenarios. It's true that the svn workflow looks more efficient and/or natural in many places, but please remember that the current workflow has evolved to deal with the specific features of Subversion compared to the DVCSes, and has had years to evolve best practices, where the PEP authors have only had a few days. I suspect that (if a DVCS is adopted) both the workflow and the best practices will evolve naturally and without much additional cost of learning to users, and arrive at a similarly efficient, but more powerful, workflow, well within a year after adoption. So there might be some rough places around the edges, especially in coming up with a way to get the functionality of svnmerge.py block, but as far as I can see, unless the project decides that it wants to adopt a decentralized workflow, the full cost of DVCS is simply learning a new VCS; the D has nothing to do with it. It won't be much harder than switching from CVS to Subversion. Again, I don't take the cost of learning a new tool lightly, but please let's call that cost by its name, and not bring distributed into it. (*) I'm probably missing something, but ISTM that committers can already use the DVCS - they only need to create a patch just before committing. That's true. It's also true that to have the benefit of distributed version control with Subversion, they only need to run a Subversion server locally. In both cases, it amounts to a fair amount of extra effort, and misses out on all the benefits of improved merging, automatic propagation of history from a merged local branch to the master repo, etc., etc. In essence, committers wanting to use a DVCS can do so today, by acting as if they were non-committers, and only using svn for actual changes to the master repository. That's false. Again, those people who want to use a DVCS as a DVCS will benefit from having the master repository(s) coordinate history for them. This doesn't work very well across VCS systems, essentially forcing all committers who want to use the distributed features to coordinate with each other directly, and only with those who use the same DVCS. The mental models used by git users, hg users, and bzr users differ significantly, though they probably differ more from the model that's appropriate for Subversion. Nevertheless, there is a lot of potential benefit to be gained from having a common DVCS for all developers. Whether the benefits available *today* and in the near future outweigh the costs of an early transition, I make no claims. But those benefits *are* fairly large, and much of the cost is subjective (based on the bad reputation of the DVCSes for UI awkwardness, especially that of git) and *may* (at this stage, I don't say will) dissipate quickly with a rather small amount of experience. ___ 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] PEP 374 (DVCS) now in reST
Michael Foord writes: If I can't choose a clear winner I am going to look into what it take to run directly on top of svn to avoid the extra step for committers. Well, that sounds like an ideal situation to end up in. Is there a downside other than the work it creates for you? I'm with Brett, the extra work for him is more than downside enough. But over and above that, the various DVCSes have different strengths and weaknesses, and their proponents have different mental models of how DVCS is supposed to work. I believe this is reflected to a great extent in their capabilities, creating great friction to trying to work with a different VCS from the native one of the master repositories. You just end up using a buttload of extra CPU cycles to achieve a Subversion-based workflow. The big advantage, IMO, to going to a DVCS for the master repo is that you can start with the same workflow currently used, and gradually adapt it to the capabilities of the more powerful tools. If we don't do that, the workflow will never really change, and the project-wide advantages of the tools will be lost. ___ 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] PEP 374 (DVCS) now in reST
On Thu, Jan 22, 2009, Brett Cannon wrote: I have now converted PEP 374 (http://www.python.org/dev/peps/pep-0374/) from Google Docs to reST and checked it in. First of all, thanks for providing PEP number, URL, and short title; that makes it much easier to keep track of the discussion on list. Second, I think it would be good to explicitly mention the option of deferring this PEP. Based on previous discussion, it sounds like there are a fair number of people who think that there is a DVCS in Python's future, but not now (where now means over the next couple of years). -- Aahz (a...@pythoncraft.com) * http://www.pythoncraft.com/ Weinberg's Second Law: If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization. ___ 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] PEP 374 (DVCS) now in reST
Aahz wrote: On Thu, Jan 22, 2009, Brett Cannon wrote: I have now converted PEP 374 (http://www.python.org/dev/peps/pep-0374/) from Google Docs to reST and checked it in. First of all, thanks for providing PEP number, URL, and short title; that makes it much easier to keep track of the discussion on list. Second, I think it would be good to explicitly mention the option of deferring this PEP. Based on previous discussion, it sounds like there are a fair number of people who think that there is a DVCS in Python's future, but not now (where now means over the next couple of years). Put me in that category - the switch from CVS to SVN was simple and obvious because SVN set out to be a better CVS and achieved that goal admirably. The only major hurdle to adopting it was getting the history across, and Martin was able to handle that in the end. The benefits of atomic commits alone were well worth the migration cost. With the level of development still going on in the DVCS area, I think this is a time when dragging our feet on making a decision may actually work to our advantage. Although if Brett genuinely wants to narrow it down to a two-horse race at PyCon, then I think the one thing to keep in mind is how well the chosen tool embodies the Zen of Python (especially Readability counts and One obvious way to do it). Core devs *are* core devs at least in part because we largely like and agree with those design philosophies. I personally find the command lines for 2 of the presented options quite pleasant to read, while the examples of using the 3rd make me shudder the way I do when I'm forced to read or write a Perl script.* Performance problems can be fixed, but an antithetical design philosophy is unlikely to make for a good tool fit. Cheers, Nick. * In other words, the examples of using git in the PEP make me want to run screaming in the opposite direction. However, assuming bzr's performance issues and line feed handling limitations are addressed by the time the switch actually happens, I'm currently fairly neutral on the choice between bzr and hg. -- 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] PEP 374 (DVCS) now in reST
On Sat, Jan 24, 2009 at 07:25, Aahz a...@pythoncraft.com wrote: On Thu, Jan 22, 2009, Brett Cannon wrote: I have now converted PEP 374 (http://www.python.org/dev/peps/pep-0374/) from Google Docs to reST and checked it in. First of all, thanks for providing PEP number, URL, and short title; that makes it much easier to keep track of the discussion on list. =) Welcome. Second, I think it would be good to explicitly mention the option of deferring this PEP. Based on previous discussion, it sounds like there are a fair number of people who think that there is a DVCS in Python's future, but not now (where now means over the next couple of years). Sure, I can add a note somewhere that says if a clear winner doesn't come about the PEP can be revisited to a later date. -Brett ___ 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] PEP 374 (DVCS) now in reST
Second, I think it would be good to explicitly mention the option of deferring this PEP. Based on previous discussion, it sounds like there are a fair number of people who think that there is a DVCS in Python's future, but not now (where now means over the next couple of years). Sure, I can add a note somewhere that says if a clear winner doesn't come about the PEP can be revisited to a later date. I think the request is slightly different: consider that a potential outcome should be svn for the next five years, then reconsider - not because none of the DVCS is a clear winner, but because there is too much resistance to DVCSes in general, at the moment. 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] PEP 374 (DVCS) now in reST
On Sat, Jan 24, 2009 at 15:34, Martin v. Löwis mar...@v.loewis.de wrote: Second, I think it would be good to explicitly mention the option of deferring this PEP. Based on previous discussion, it sounds like there are a fair number of people who think that there is a DVCS in Python's future, but not now (where now means over the next couple of years). Sure, I can add a note somewhere that says if a clear winner doesn't come about the PEP can be revisited to a later date. I think the request is slightly different: consider that a potential outcome should be svn for the next five years, then reconsider - not because none of the DVCS is a clear winner, but because there is too much resistance to DVCSes in general, at the moment. I already put a note in that no DVCS might be chosen once the PEP is finished. Whether it is because no DVCS is a clear improvement over svn or people just don't like a DVCS seems like a minor thing to worry about to spell out in the PEP. -Brett ___ 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] PEP 374 (DVCS) now in reST
Brett Cannon wrote: On Sat, Jan 24, 2009 at 15:34, Martin v. Löwis mar...@v.loewis.de wrote: Second, I think it would be good to explicitly mention the option of deferring this PEP. Based on previous discussion, it sounds like there are a fair number of people who think that there is a DVCS in Python's future, but not now (where now means over the next couple of years). Sure, I can add a note somewhere that says if a clear winner doesn't come about the PEP can be revisited to a later date. I think the request is slightly different: consider that a potential outcome should be svn for the next five years, then reconsider - not because none of the DVCS is a clear winner, but because there is too much resistance to DVCSes in general, at the moment. I already put a note in that no DVCS might be chosen once the PEP is finished. Whether it is because no DVCS is a clear improvement over svn or people just don't like a DVCS seems like a minor thing to worry about to spell out in the PEP. I suspect the reactions will be more nuanced than that anyway - e.g. my current position is that while I like the idea of a DVCS in principle and agree there are definite gains to be had in switching to one, I don't think the contenders have had enough time to shake out their competing feature sets and relative performance. We don't seem to lose a lot by sticking with SVN at least until after 2.7/3.1 are out the door and then revisiting the DVCS question (this is particularly so given that the current plan is go for a fairly short turnaround on those two releases). As the zen says, now is better than never, but never is often better than *right* now :) 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] PEP 374 (DVCS) now in reST
On Sat, Jan 24, 2009 at 16:44, Nick Coghlan ncogh...@gmail.com wrote: Brett Cannon wrote: On Sat, Jan 24, 2009 at 15:34, Martin v. Löwis mar...@v.loewis.de wrote: Second, I think it would be good to explicitly mention the option of deferring this PEP. Based on previous discussion, it sounds like there are a fair number of people who think that there is a DVCS in Python's future, but not now (where now means over the next couple of years). Sure, I can add a note somewhere that says if a clear winner doesn't come about the PEP can be revisited to a later date. I think the request is slightly different: consider that a potential outcome should be svn for the next five years, then reconsider - not because none of the DVCS is a clear winner, but because there is too much resistance to DVCSes in general, at the moment. I already put a note in that no DVCS might be chosen once the PEP is finished. Whether it is because no DVCS is a clear improvement over svn or people just don't like a DVCS seems like a minor thing to worry about to spell out in the PEP. I suspect the reactions will be more nuanced than that anyway - e.g. my current position is that while I like the idea of a DVCS in principle and agree there are definite gains to be had in switching to one, I don't think the contenders have had enough time to shake out their competing feature sets and relative performance. We don't seem to lose a lot by sticking with SVN at least until after 2.7/3.1 are out the door and then revisiting the DVCS question (this is particularly so given that the current plan is go for a fairly short turnaround on those two releases). As part of my impressions I plan to also look at usage on top of svn as a viable alternative if no clear winner comes about. That way if they work well directly on top of svn we can write up very clear documentation on how to use any of them directly on top of svn and still gain the benefits of offline checkins and cheap branching. Maintenance then becomes simply keeping a read-only mirror going on code.python.org. As the zen says, now is better than never, but never is often better than *right* now :) Don't worry, I am not going to push something down anyone's throats if I don't feel secure that it is the best choice. ___ 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] PEP 374 (DVCS) now in reST
And I would like to thank my co-authors for their time and effort thus far in filling in the PEP on behalf of their favorite DVCS. Everyone has put in a lot of time already with I am sure more time in the future. So what will happen next? ISTM that the PEP is not complete, since it doesn't specify a specific DVCS to migrate to (i.e. it wouldn't be possible to implement the PEP as it stands). Somebody will have to make a decision. Ultimately, Guido will have to approve the PEP, but it might be that he refuses to make a choice of specific DVCS. Traditionally, it is the PEP author who makes all choices (considering suggestions from the community, of course). So what DVCS do the PEP authors recommend? 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] PEP 374 (DVCS) now in reST
Martin v. Löwis martin at v.loewis.de writes: Somebody will have to make a decision. Ultimately, Guido will have to approve the PEP, but it might be that he refuses to make a choice of specific DVCS. Traditionally, it is the PEP author who makes all choices (considering suggestions from the community, of course). So what DVCS do the PEP authors recommend? Brett mentioned in his email that he wasn't ready to make a decision yet, I think? I also think that the PEP could still use some modifications from people who have more experience with the DVCSs. I'll probably send in some suggestions later today. 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] PEP 374 (DVCS) now in reST
Brett Cannon brett at python.org writes: I have now converted PEP 374 (http://www.python.org/dev/peps/pep-0374/) from Google Docs to reST and checked it in. I am not going to paste it into an email as it is nearly 1500 lines in reST form. It seems the token is mangled into a French closing quote (») inside code snippets. 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] PEP 374 (DVCS) now in reST
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brett, thanks for putting this PEP together! On Jan 23, 2009, at 3:39 AM, Martin v. Löwis wrote: Somebody will have to make a decision. Ultimately, Guido will have to approve the PEP, but it might be that he refuses to make a choice of specific DVCS. Traditionally, it is the PEP author who makes all choices (considering suggestions from the community, of course). So what DVCS do the PEP authors recommend? Brett, perhaps you should publish a tentative schedule. Milestones I'd like to see include * Initial impressions section completed * Call for rebuttals * Second draft of impressions * (perhaps multiple) Recommendations to Guido and python-dev * Experimental live branches deployed for testing * Final recommendation * Final decision My understanding is that a final decision will /not/ be made by Pycon. Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSXnis3EjvBPtnXfVAQJTqwQAimSA/JDzYN132npgazIag3fwOk36DAJl vvYMXOfWqvfl9DO/8cPF9YFOwF7YdHM8k4wUTmfLYhE8JfefODjrdHkL5pdclwDg Pbb2tjMfl0vBOPeaaPnJ5NKIJMwyRWkVhFMyNU5KmBmVRPJXpAQM23IOORX2dAaI tLONmrvx8K4= =CF18 -END 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] PEP 374 (DVCS) now in reST
On Fri, Jan 23, 2009 at 00:39, Martin v. Löwis mar...@v.loewis.de wrote:
And I would like to thank my co-authors for their time and effort thus
far in filling in the PEP on behalf of their favorite DVCS. Everyone
has put in a lot of time already with I am sure more time in the
future.
So what will happen next? ISTM that the PEP is not complete, since it
doesn't specify a specific DVCS to migrate to (i.e. it wouldn't be
possible to implement the PEP as it stands).
Right, it isn't done. But I know from experience people care A LOT
about their favorite DVCS, so I wanted to get the PEP up now so people
can start sending in feedback to the proper authors instead of having
it all flood in after I have done my exploratory work on all of them
and be accused of having based my decision on faulty information.
Somebody will have to make a decision.
That falls on my shoulders.
Ultimately, Guido will have to
approve the PEP, but it might be that he refuses to make a choice of
specific DVCS.
Guido is staying out of this one.
Traditionally, it is the PEP author who makes all
choices (considering suggestions from the community, of course). So
what DVCS do the PEP authors recommend?
Umm::
import random
print(random.choice('svn', 'bzr', 'hg', 'git'))
-Brett
___
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] PEP 374 (DVCS) now in reST
On Fri, Jan 23, 2009 at 03:05, Antoine Pitrou solip...@pitrou.net wrote: Brett Cannon brett at python.org writes: I have now converted PEP 374 (http://www.python.org/dev/peps/pep-0374/) from Google Docs to reST and checked it in. I am not going to paste it into an email as it is nearly 1500 lines in reST form. It seems the token is mangled into a French closing quote (») inside code snippets. Yeah, the Google Docs export didn't come out well in pure text. I tried to catch as many of those characters as I could but apparently I missed a couple. -Brett ___ 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] PEP 374 (DVCS) now in reST
On Fri, Jan 23, 2009 at 07:30, Barry Warsaw ba...@python.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brett, thanks for putting this PEP together! Yep. Just make sure I don't do something like this for a LONG time. Apparently I didn't learn my lesson after the issue tracker migration. On Jan 23, 2009, at 3:39 AM, Martin v. Löwis wrote: Somebody will have to make a decision. Ultimately, Guido will have to approve the PEP, but it might be that he refuses to make a choice of specific DVCS. Traditionally, it is the PEP author who makes all choices (considering suggestions from the community, of course). So what DVCS do the PEP authors recommend? Brett, perhaps you should publish a tentative schedule. Milestones I'd like to see include * Initial impressions section completed * Call for rebuttals * Second draft of impressions * (perhaps multiple) Recommendations to Guido and python-dev * Experimental live branches deployed for testing * Final recommendation * Final decision I think you just published the schedule, Barry. =) Seriously, though, I have several other commitments that take precedent over this PEP so I don't feel comfortable locking down any dates. My understanding is that a final decision will /not/ be made by Pycon. It's doubtful, but would be nice by then. What I will do is eliminate a contender by/at PyCon. -Brett ___ 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] PEP 374 (DVCS) now in reST
import random
print(random.choice('svn', 'bzr', 'hg', 'git'))
Nice! So it's bzr, as my machine just told me (after adding
the square brackets).
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] PEP 374 (DVCS) now in reST
On Fri, Jan 23, 2009 at 12:06 PM, Martin v. Löwis mar...@v.loewis.de wrote:
import random
print(random.choice('svn', 'bzr', 'hg', 'git'))
Nice! So it's bzr, as my machine just told me (after adding
the square brackets).
Wow, that decision was a lot easier than I thought it would be. ;-)
Steve
--
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
--- Bucky Katt, Get Fuzzy
___
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] PEP 374 (DVCS) now in reST
On Fri, Jan 23, 2009 at 12:11, Steven Bethard steven.beth...@gmail.com wrote:
On Fri, Jan 23, 2009 at 12:06 PM, Martin v. Löwis mar...@v.loewis.de
wrote:
import random
print(random.choice('svn', 'bzr', 'hg', 'git'))
Nice! So it's bzr, as my machine just told me (after adding
the square brackets).
Wow, that decision was a lot easier than I thought it would be. ;-)
But my machine just told me svn, which is even easier as that means we
don't need to change anything. =)
-Brett
___
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] PEP 374 (DVCS) now in reST
Brett mentioned in his email that he wasn't ready to make a decision yet, I think? I also think that the PEP could still use some modifications from people who have more experience with the DVCSs. My question really was whether it is already ready for the wider audience up for discussion (and if so, what it is that should be discussed). It seems that it's not the case, so I just sit back and wait until its ready. 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] PEP 374 (DVCS) now in reST
2009/1/23 Martin v. Löwis mar...@v.loewis.de: Brett mentioned in his email that he wasn't ready to make a decision yet, I think? I also think that the PEP could still use some modifications from people who have more experience with the DVCSs. My question really was whether it is already ready for the wider audience up for discussion (and if so, what it is that should be discussed). It seems that it's not the case, so I just sit back and wait until its ready. That's the impression I got - until Brett reaches the point of Call for rebuttals, he's not looking for input (other than factual corrections of the capability and scenario sections). I'm not sure I'm comfortable with sitting back and waiting to quite that extent (I'm *already* biting my tongue over some of Brett's comments with which I strongly disagree), but I'd rather not have the PEP dissolve in a flamewar before Brett has a chance to study things better. I appreciate the need for a considered, logical evaluation, but I'm not sure keeping the lid on the impassioned arguments is going to make them any less likely to explode when they finally do happen. Paul. ___ 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] PEP 374 (DVCS) now in reST
On Fri, Jan 23, 2009 at 13:39, Paul Moore p.f.mo...@gmail.com wrote: 2009/1/23 Martin v. Löwis mar...@v.loewis.de: Brett mentioned in his email that he wasn't ready to make a decision yet, I think? I also think that the PEP could still use some modifications from people who have more experience with the DVCSs. My question really was whether it is already ready for the wider audience up for discussion (and if so, what it is that should be discussed). It seems that it's not the case, so I just sit back and wait until its ready. That's the impression I got - until Brett reaches the point of Call for rebuttals, he's not looking for input (other than factual corrections of the capability and scenario sections). That's right. I'm not sure I'm comfortable with sitting back and waiting to quite that extent (I'm *already* biting my tongue over some of Brett's comments with which I strongly disagree), but I'd rather not have the PEP dissolve in a flamewar before Brett has a chance to study things better. It's going to dissolve anyway. I am just trying to keep it to a single situation instead of having to go over it multiple times. I appreciate the need for a considered, logical evaluation, but I'm not sure keeping the lid on the impassioned arguments is going to make them any less likely to explode when they finally do happen. I know it will explode. I am just trying to save myself the time of not having to reply to the flood of emails that I know will come before I have finished even thinking things through. It's like people asking questions during a presentation that happen to be strongly affected by the next slide; you can ask, but you might as well wait until all the info is presented to start talking. -Brett ___ 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] PEP 374 (DVCS) now in reST
Brett Cannon wrote: On Fri, Jan 23, 2009 at 13:39, Paul Moore p.f.mo...@gmail.com wrote: I'm not sure I'm comfortable with sitting back and waiting to quite that extent (I'm *already* biting my tongue over some of Brett's comments with which I strongly disagree), but I'd rather not have the PEP dissolve in a flamewar before Brett has a chance to study things better. It's going to dissolve anyway. I am just trying to keep it to a single situation instead of having to go over it multiple times. I have two suggestions: 1. Conduct the discussion on python-ideas rather than python-dev so as to not overwhelm the day-to-day discussions and also to provide a bit of psychological distance. 2. Have several focused threads. Some examples: Given three experimental setups a. Experience with bzr b. Experience with hg c. Experience with git later d. Comparisons based on real experience Your different comments might best be separately discussed. In the PEP, I said 'blah, blah'. Comments? Terry ___ 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] PEP 374 (DVCS) now in reST
Brett Cannon wrote:
On Fri, Jan 23, 2009 at 12:11, Steven Bethard steven.beth...@gmail.com
wrote:
On Fri, Jan 23, 2009 at 12:06 PM, Martin v. Löwis mar...@v.loewis.de
wrote:
import random
print(random.choice('svn', 'bzr', 'hg', 'git'))
Nice! So it's bzr, as my machine just told me (after adding
the square brackets).
Wow, that decision was a lot easier than I thought it would be. ;-)
But my machine just told me svn, which is even easier as that means we
don't need to change anything. =)
Mine briefly flirted with git, but quickly changed its mind. It *is* a
Kubuntu machine though, so it's probably biased :)
Cheers,
Nick.
import random
random.choice(['svn', 'bzr', 'hg', 'git'])
'git'
random.choice(['svn', 'bzr', 'hg', 'git'])
'bzr'
random.choice(['svn', 'bzr', 'hg', 'git'])
'bzr'
random.choice(['svn', 'bzr', 'hg', 'git'])
'bzr'
--
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
[Python-Dev] PEP 374 (DVCS) now in reST
I have now converted PEP 374 (http://www.python.org/dev/peps/pep-0374/) from Google Docs to reST and checked it in. I am not going to paste it into an email as it is nearly 1500 lines in reST form. Because there are four authors handling corrections it is a little different than normal on who you contact to suggest changes. For each specific VCS there is a primary author as listed in the PEP in the intro to the Scenarios section. Email the proper author if you find an issue with a specific VCS. Otherwise email me for general PEP issues. Core developers can make changes on their own while taking into account they should let the author in charge of the PEP know if they make a big change. Since I will be the author making the final recommendation I am documenting my thought processes on my decision making for this whole thing as I go along in the PEP so as to be as transparent as possible. I am not even close to being done, so please don't email me about the section. And I would like to thank my co-authors for their time and effort thus far in filling in the PEP on behalf of their favorite DVCS. Everyone has put in a lot of time already with I am sure more time in the future. -Brett ___ 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
