I'm preparing the argparse module for the 2.7 and 3.2 branches. Could someone remind me again what the commit process is? Commit to 2.7 and merge to 3.2? And do we merge with svnmerge.py or svn merge? There's probably a webpage explaining this somewhere, but my Google-fu is failing me right now.
Thanks,
Steve
Where did you get that preposterous hypothesis? Did Steve tell you that? --- The Hiphopopotamus
Steven Bethard wrote:
I'm preparing the argparse module for the 2.7 and 3.2 branches. Could someone remind me again what the commit process is? Commit to 2.7 and merge to 3.2? And do we merge with svnmerge.py or svn merge? There's probably a webpage explaining this somewhere, but my Google-fu is failing me right now.
http://www.python.org/dev/faq/#how-do-i-merge-between-branches
Use svnmerge.py. Commit to trunk, then merge to py3k. You'll probably want to block release26-maint and release31-maint.
Eric.
On Mon, Mar 1, 2010 at 1:16 AM, Eric Smith <eric@trueblade.com> wrote:
Steven Bethard wrote:
I'm preparing the argparse module for the 2.7 and 3.2 branches. Could someone remind me again what the commit process is? Commit to 2.7 and merge to 3.2? And do we merge with svnmerge.py or svn merge? There's probably a webpage explaining this somewhere, but my Google-fu is failing me right now.
http://www.python.org/dev/faq/#how-do-i-merge-between-branches
Use svnmerge.py. Commit to trunk, then merge to py3k. You'll probably want to block release26-maint and release31-maint.
Eric.
Why bother explicitly blocking it in release26-maint and release31-maint? That just seems like extra svn makework given it won't be merged into those branches anyways as a matter of policy.
-gps
Gregory P. Smith wrote:
On Mon, Mar 1, 2010 at 1:16 AM, Eric Smith <eric@trueblade.com> wrote:
Steven Bethard wrote:
I'm preparing the argparse module for the 2.7 and 3.2 branches. Could someone remind me again what the commit process is? Commit to 2.7 and merge to 3.2? And do we merge with svnmerge.py or svn merge? There's probably a webpage explaining this somewhere, but my Google-fu is failing me right now. http://www.python.org/dev/faq/#how-do-i-merge-between-branches
Use svnmerge.py. Commit to trunk, then merge to py3k. You'll probably want to block release26-maint and release31-maint.
Eric.
Why bother explicitly blocking it in release26-maint and release31-maint? That just seems like extra svn makework given it won't be merged into those branches anyways as a matter of policy.
Because the FAQ tells me to do so!
I've been doing it to remind myself of things that need to be merged, or not. And I believe it used to be used by people doing mass-merges, I'm not sure if that is done any more.
A few of us discussed this at the sprint. I think an official policy on the issue would be a good thing, since people are of 2 minds about it.
Eric.
On Mon, Mar 1, 2010 at 09:31, Eric Smith <eric@trueblade.com> wrote:
Gregory P. Smith wrote:
On Mon, Mar 1, 2010 at 1:16 AM, Eric Smith <eric@trueblade.com> wrote:
Steven Bethard wrote:
I'm preparing the argparse module for the 2.7 and 3.2 branches. Could someone remind me again what the commit process is? Commit to 2.7 and merge to 3.2? And do we merge with svnmerge.py or svn merge? There's probably a webpage explaining this somewhere, but my Google-fu is failing me right now.
http://www.python.org/dev/faq/#how-do-i-merge-between-branches
Use svnmerge.py. Commit to trunk, then merge to py3k. You'll probably want to block release26-maint and release31-maint.
Eric.
Why bother explicitly blocking it in release26-maint and release31-maint? That just seems like extra svn makework given it won't be merged into those branches anyways as a matter of policy.
Because the FAQ tells me to do so!
I've been doing it to remind myself of things that need to be merged, or not. And I believe it used to be used by people doing mass-merges, I'm not sure if that is done any more.
Georg and Benjamin used to do it on occasion back when people did not do any primary development in py3k or would just forget because it was not habit yet.
A few of us discussed this at the sprint. I think an official policy on the issue would be a good thing, since people are of 2 minds about it.
I say we keep doing it in case someone does one last blind merge before we switch to Hg.
-Brett
I say we keep doing it in case someone does one last blind merge before we switch to Hg.
That would fail terribly, as there are tons of unblocked changes that shouldn't be merged, either.
I don't want to argue about policy at this point, but I don't feel particularly bad myself when I forget to block changes.
Regards, Martin
On Mon, Mar 1, 2010 at 13:10, "Martin v. Löwis" <martin@v.loewis.de> wrote:
I say we keep doing it in case someone does one last blind merge before we switch to Hg.
That would fail terribly, as there are tons of unblocked changes that shouldn't be merged, either.
I don't want to argue about policy at this point, but I don't feel particularly bad myself when I forget to block changes.
Well, if we are already screwed if we do a blind merge we might as well stop wasting our time on doing blocks since that is the only real use case for bothering.
-Brett
Regards, Martin
On Mar 01, 2010, at 02:06 PM, Brett Cannon wrote:
Well, if we are already screwed if we do a blind merge we might as well stop wasting our time on doing blocks since that is the only real use case for bothering.
Maybe we should consider switching to hg now rather than waiting? (Well, by "now" I mean after I release 2.6.5 :). We're still a month away from 2.7 beta 1 and 6+ months away from 3.2 beta 1. If svn is hopeless (and my vote is that it is) let's do the switch now with plenty of time to shake out the pain. Nothing like angry developers to motivate that, and at least now that Pycon's over, physical intimidation is more difficult. :)
Seriously though, do we really have to wait until 2.7 is released?
-Barry
On Mon, Mar 1, 2010 at 14:24, Barry Warsaw <barry@python.org> wrote:
On Mar 01, 2010, at 02:06 PM, Brett Cannon wrote:
Well, if we are already screwed if we do a blind merge we might as well stop wasting our time on doing blocks since that is the only real use case for bothering.
Maybe we should consider switching to hg now rather than waiting? (Well, by "now" I mean after I release 2.6.5 :). We're still a month away from 2.7 beta 1 and 6+ months away from 3.2 beta 1. If svn is hopeless (and my vote is that it is) let's do the switch now with plenty of time to shake out the pain. Nothing like angry developers to motivate that, and at least now that Pycon's over, physical intimidation is more difficult. :)
Seriously though, do we really have to wait until 2.7 is released?
The hold-up will ultimately be the EOL extension and the updated docs now that Dirkjan has a patch for sys.mercurial. The 2.7 date was to give a target date push those last two items to be done.
-Brett
-Barry
python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
On Mon, Mar 1, 2010 at 21:18, "Martin v. Löwis" <martin@v.loewis.de> wrote:
The hold-up will ultimately be the EOL extension and the updated docs now that Dirkjan has a patch for sys.mercurial.
Is that patch published somewhere? I'd like to take a look.
Dirkjan would know where the patch is.
-Brett
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/01/2010 11:24 PM, Barry Warsaw wrote:
Maybe we should consider switching to hg now rather than waiting?
I can't wait for HG. I have read the main cutprit for the delay is the line-ending issue with MS Windows developers. Is there anything else holding us back?.
(And yes, maybe migrating would do people angry enough for solving the last details :-).
Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQCVAwUBS4yHyplgi5GaxT1NAQK0SgP+KFtKJEhqhuRs0aXjrx+A5Udm2Gignimq MU+i2gwVljcFawxTwfROabhkftgutL6gs9nbY1rL2F54jQvWETvSYMYoJqjBDCdL 9urWaNZkQa1gN26hXu0084pnwfz6cfPwavdMmZnyfeTkGtTaby1PAX1F2LWKpvZD LlHSc6xovFo= =YwIa -----END PGP SIGNATURE-----
On Tue, Mar 02, 2010 at 04:36:42AM +0100, Jesus Cea wrote:
I can't wait for HG. I have read the main cutprit for the delay is the line-ending issue with MS Windows developers. Is there anything else holding us back?.
Note that, if you'd just like to use Mercurial for your own convenience while developing, the mirrored repositories at http://hg.python.org/ are up-to-date; you just can't push changes back. I have a regex patch that was developed using an hg checkout of the Python source tree, with my changes layered atop it using the mq extension.
--amk
On Mar 02, 2010, at 08:21 AM, A.M. Kuchling wrote:
On Tue, Mar 02, 2010 at 04:36:42AM +0100, Jesus Cea wrote:
I can't wait for HG. I have read the main cutprit for the delay is the line-ending issue with MS Windows developers. Is there anything else holding us back?.
Note that, if you'd just like to use Mercurial for your own convenience while developing, the mirrored repositories at http://hg.python.org/ are up-to-date; you just can't push changes back. I have a regex patch that was developed using an hg checkout of the Python source tree, with my changes layered atop it using the mq extension.
We really need to move to a dvcs for development sooner rather than later. It's been a year since the decision was made. I understand that it will suck for Windows developers in the short term, but with all the discussion about the PSF paying for pdo infrastructure work, I think getting us off of Subversion would have the most immediate positive impact for development of Python. If the EOL issue is the holdup, what can we do *right now* to break that logjam? Can't the PSF pay somebody to make this happen?
-Barry
On Tue, Mar 2, 2010 at 15:17, Barry Warsaw <barry@python.org> wrote:
We really need to move to a dvcs for development sooner rather than later. It's been a year since the decision was made. I understand that it will suck for Windows developers in the short term, but with all the discussion about the PSF paying for pdo infrastructure work, I think getting us off of Subversion would have the most immediate positive impact for development of Python. If the EOL issue is the holdup, what can we do *right now* to break that logjam? Can't the PSF pay somebody to make this happen?
For the EOL issue, there is code, it needs testing. Martin Geisler (the primary author so far) and I issued a call for testing on python-dev last week, but without any response so far. As for paying someone, I have a full-time job already, so I don't really have the time to do consulting. I could ask around for other Mercurial team members, but I'm not sure there's much point to it if no one is testing the extension that exists right now.
The other thing is that I need a good way to prune branches. I wrote up some code to do branch renaming last week, but there's another issue to tackle. Meanwhile, I've been busy with moving ahead on the Jython conversion, since they don't have the EOL requirements at this time. I hope to complete that project this week. I've also been setting up some infrastructure last week, to make it usable for distutils2/unittest2. I set up changegroup (i.e. push) emails to python-checkins for distutils2 last night, but I'm not sure the first email got through (might be stuck in moderation?).
Cheers,
Dirkjan
Le Tue, 2 Mar 2010 15:41:45 +0100, Dirkjan Ochtman <dirkjan@ochtman.nl> a écrit :
For the EOL issue, there is code, it needs testing. Martin Geisler (the primary author so far) and I issued a call for testing on python-dev last week, but without any response so far.
The people who have voiced their annoyance at the EOL situation should do the testing, really. If they don't want to do it, then IMO we should move forward anyway. There are more pressing issues involved in the Mercurial transition (for example, what we will replace the svnmerge process with) and I find it a bit annoying that we have to focus on the micro-issue of EOL translation, which (judging by mailing-list archives) doesn't seem to affect the Windows-based Mercurial users at large.
Regards
Antoine.
Antoine Pitrou wrote:
Le Tue, 2 Mar 2010 15:41:45 +0100, Dirkjan Ochtman <dirkjan@ochtman.nl> a écrit :
For the EOL issue, there is code, it needs testing. Martin Geisler (the primary author so far) and I issued a call for testing on python-dev last week, but without any response so far.
The people who have voiced their annoyance at the EOL situation should do the testing, really. If they don't want to do it, then IMO we should move forward anyway. There are more pressing issues involved in the Mercurial transition (for example, what we will replace the svnmerge process with) and I find it a bit annoying that we have to focus on the micro-issue of EOL translation, which (judging by mailing-list archives) doesn't seem to affect the Windows-based Mercurial users at large.
I expended a good deal of effort last year making sure that core developers who required them got MSDN licenses. This should surely enable some testing. If nobody wants to test for the Windows platform then all the work is going to fall on MvL, who surely has plenty to do without that additional load.
IMHO we got in this mess because we didn't have sufficient involvement from Windows platform users during the DVCS evaluation - people saw that there was some accommodation to Windows, and assumed it would be sufficient for our purposes. It wasn't, and a year later we are only just approaching a solution.
This is a big deal, and it needs some effort. Doesn't *anyone* have time?
regards Steve
Steve Holden +1 571 484 6266 +1 800 494 3119 PyCon is coming! Atlanta, Feb 2010 http://us.pycon.org/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS: http://holdenweb.eventbrite.com/
Le Tue, 02 Mar 2010 10:29:13 -0500, Steve Holden <steve@holdenweb.com> a écrit :
IMHO we got in this mess because we didn't have sufficient involvement from Windows platform users during the DVCS evaluation - people saw that there was some accommodation to Windows, and assumed it would be sufficient for our purposes. It wasn't, and a year later we are only just approaching a solution.
It's still unclear that it's not sufficient, though. To me it seems more like a case of striving for perfection while the current situation should be good enough. In other words, I'm not willing to spend any of my time on what looks to me like a non-issue.
Regards
Antoine.
Antoine Pitrou wrote:
Le Tue, 02 Mar 2010 10:29:13 -0500, Steve Holden <steve@holdenweb.com> a écrit :
IMHO we got in this mess because we didn't have sufficient involvement from Windows platform users during the DVCS evaluation - people saw that there was some accommodation to Windows, and assumed it would be sufficient for our purposes. It wasn't, and a year later we are only just approaching a solution.
It's still unclear that it's not sufficient, though. To me it seems more like a case of striving for perfection while the current situation should be good enough. In other words, I'm not willing to spend any of my time on what looks to me like a non-issue.
And does it look like a non-issue because you are familiar with the Windows environment or because your imagination can't conceive of why it would be a real problem? Does going ahead make development more difficult for the Windows platform? I'm not fully familiar with the issues, but if they were significant enough to persuade Brett that Hg shouldn't go ahead I have to believe they are potential show-stoppers.
I'd rather *know* it was a non-issue than *assume* (as Windows developers did when Hg was mooted) it was a non-issue and then find out that it's real.
Ultimately it's up to the core development team. From the outside I see support for a major platform becoming tenuous, and that concerns me. Where's Tim Peters when you need him?
regards Steve
Steve Holden +1 571 484 6266 +1 800 494 3119 PyCon is coming! Atlanta, Feb 2010 http://us.pycon.org/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS: http://holdenweb.eventbrite.com/
On Tue, Mar 2, 2010 at 17:12, Steve Holden <steve@holdenweb.com> wrote:
And does it look like a non-issue because you are familiar with the Windows environment or because your imagination can't conceive of why it would be a real problem? Does going ahead make development more difficult for the Windows platform? I'm not fully familiar with the issues, but if they were significant enough to persuade Brett that Hg shouldn't go ahead I have to believe they are potential show-stoppers.
It's perceived as not much of an issue, AFAICT, because people feel that using good editors will save you most of the time, pre-push hooks will prevent everyone from actually polluting the central repository, and it would be easy to install pre-commit hooks locally to get an early warning. ISTM that the remaining problem space is a high level of automation that some Windows developers desire, that they got from SVN, but that is quite small because there's a bunch of mitigating factors. It's perceived as a regression, and as making Windows developers second class because most of the issues won't come up on other systems.
Cautiously formulating-ly,
Dirkjan
On 02/03/2010 16:41, Dirkjan Ochtman wrote:
On Tue, Mar 2, 2010 at 17:12, Steve Holden<steve@holdenweb.com> wrote:
And does it look like a non-issue because you are familiar with the Windows environment or because your imagination can't conceive of why it would be a real problem? Does going ahead make development more difficult for the Windows platform? I'm not fully familiar with the issues, but if they were significant enough to persuade Brett that Hg shouldn't go ahead I have to believe they are potential show-stoppers.
It's perceived as not much of an issue, AFAICT, because people feel that using good editors will save you most of the time, pre-push hooks will prevent everyone from actually polluting the central repository, and it would be easy to install pre-commit hooks locally to get an early warning. ISTM that the remaining problem space is a high level of automation that some Windows developers desire, that they got from SVN, but that is quite small because there's a bunch of mitigating factors. It's perceived as a regression, and as making Windows developers second class because most of the issues won't come up on other systems.
What is the risk of going ahead with a broken system?
The crux of the matter is that building Python for Windows could break if someone accidentally commits the wrong line-endings for a few specific files (Visual Studio project and configuration files - do I understand correctly?). If this happens, how hard a job would it be to find and fix the problem?
The risk *seems* reasonably low, people on non-Windows platforms are unlikely to touch those files and they are unlikely to be edited by hand, and if the cost of fixing the problem is low it seems reasonable to migrate earlier rather than later.
Would it help for the PSF to pay someone to do the necessary testing + coding to ensure the problem is fixed and is there a likely person we could contract?
All the best,
Michael Foord
Cautiously formulating-ly,
Dirkjan
python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog
READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
On Tue, Mar 2, 2010 at 17:52, Michael Foord <mfoord@python.org> wrote:
What is the risk of going ahead with a broken system?
The crux of the matter is that building Python for Windows could break if someone accidentally commits the wrong line-endings for a few specific files (Visual Studio project and configuration files - do I understand correctly?). If this happens, how hard a job would it be to find and fix the problem?
That wouldn't happen, because we'd have pre-push hooks in place that prevent changesets changing something for the worse from going into the central repository. That places a certain burden on people who run into these issues to fix up their changesets, though. The argument was, I think, that it's not reasonable for Windows developers to have to spend time on fixing up their own changesets when other developers don't have to do so.
The risk *seems* reasonably low, people on non-Windows platforms are unlikely to touch those files and they are unlikely to be edited by hand, and if the cost of fixing the problem is low it seems reasonable to migrate earlier rather than later.
IMO the risk is negligible, due to the aformentioned precautions.
Would it help for the PSF to pay someone to do the necessary testing + coding to ensure the problem is fixed and is there a likely person we could contract?
Matt Mackall, the founder of Mercurial, might be available. Martin Geisler is the person who did most of the work on the eol extension so far, including getting a Windows laptop from his university to try some things, but I'm not sure he's available either. I could ask around, though, if the PSF thinks spending money on this is worthwhile.
Cheers,
Dirkjan
Dirkjan Ochtman wrote:
On Tue, Mar 2, 2010 at 17:52, Michael Foord <mfoord@python.org> wrote:
What is the risk of going ahead with a broken system?
The crux of the matter is that building Python for Windows could break if someone accidentally commits the wrong line-endings for a few specific files (Visual Studio project and configuration files - do I understand correctly?). If this happens, how hard a job would it be to find and fix the problem?
That wouldn't happen, because we'd have pre-push hooks in place that prevent changesets changing something for the worse from going into the central repository. That places a certain burden on people who run into these issues to fix up their changesets, though. The argument was, I think, that it's not reasonable for Windows developers to have to spend time on fixing up their own changesets when other developers don't have to do so.
The risk *seems* reasonably low, people on non-Windows platforms are unlikely to touch those files and they are unlikely to be edited by hand, and if the cost of fixing the problem is low it seems reasonable to migrate earlier rather than later.
IMO the risk is negligible, due to the aformentioned precautions.
Would it help for the PSF to pay someone to do the necessary testing + coding to ensure the problem is fixed and is there a likely person we could contract?
Matt Mackall, the founder of Mercurial, might be available. Martin Geisler is the person who did most of the work on the eol extension so far, including getting a Windows laptop from his university to try some things, but I'm not sure he's available either. I could ask around, though, if the PSF thinks spending money on this is worthwhile.
The PSF would look to the developer community for advice on this issue, but if it's holding the DVCS switch up I can't think of many objections to spending a modest sum to remove the issue.
regards Steve
Steve Holden +1 571 484 6266 +1 800 494 3119 PyCon is coming! Atlanta, Feb 2010 http://us.pycon.org/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS: http://holdenweb.eventbrite.com/
On Tue, Mar 2, 2010 at 12:59 PM, Steve Holden <steve@holdenweb.com> wrote:
Dirkjan Ochtman wrote:
On Tue, Mar 2, 2010 at 17:52, Michael Foord <mfoord@python.org> wrote:
What is the risk of going ahead with a broken system?
The crux of the matter is that building Python for Windows could break if someone accidentally commits the wrong line-endings for a few specific files (Visual Studio project and configuration files - do I understand correctly?). If this happens, how hard a job would it be to find and fix the problem?
That wouldn't happen, because we'd have pre-push hooks in place that prevent changesets changing something for the worse from going into the central repository. That places a certain burden on people who run into these issues to fix up their changesets, though. The argument was, I think, that it's not reasonable for Windows developers to have to spend time on fixing up their own changesets when other developers don't have to do so.
The risk *seems* reasonably low, people on non-Windows platforms are unlikely to touch those files and they are unlikely to be edited by hand, and if the cost of fixing the problem is low it seems reasonable to migrate earlier rather than later.
IMO the risk is negligible, due to the aformentioned precautions.
Would it help for the PSF to pay someone to do the necessary testing + coding to ensure the problem is fixed and is there a likely person we could contract?
Matt Mackall, the founder of Mercurial, might be available. Martin Geisler is the person who did most of the work on the eol extension so far, including getting a Windows laptop from his university to try some things, but I'm not sure he's available either. I could ask around, though, if the PSF thinks spending money on this is worthwhile.
The PSF would look to the developer community for advice on this issue, but if it's holding the DVCS switch up I can't think of many objections to spending a modest sum to remove the issue.
+100
jesse
On Tue, Mar 2, 2010 at 18:01, Dirkjan Ochtman <dirkjan@ochtman.nl> wrote:
The risk *seems* reasonably low, people on non-Windows platforms are unlikely to touch those files and they are unlikely to be edited by hand, and if the cost of fixing the problem is low it seems reasonable to migrate earlier rather than later.
IMO the risk is negligible, due to the aformentioned precautions.
Qualifying this somewhat: the *technical* risk is negligible.
As for the social risk, that's a different story.
Cheers,
Dirkjan
Le Tue, 2 Mar 2010 20:18:16 +0100, Dirkjan Ochtman <dirkjan@ochtman.nl> a écrit :
On Tue, Mar 2, 2010 at 18:01, Dirkjan Ochtman <dirkjan@ochtman.nl> wrote:
The risk *seems* reasonably low, people on non-Windows platforms are unlikely to touch those files and they are unlikely to be edited by hand, and if the cost of fixing the problem is low it seems reasonable to migrate earlier rather than later.
IMO the risk is negligible, due to the aformentioned precautions.
Qualifying this somewhat: the *technical* risk is negligible.
As for the social risk, that's a different story.
That was also my sentiment. These issues seem to be overestimated, or perceived as a lack of care for the Windows platform.
This perception is wrong, I do care as much as others about the Windows platform. It's just that having to manually run a script from time to time if your editor screws up is not a big deal. I have to do it myself, when SVN refuses my commit and tells me to run Tools/reindent.py.
It is also why it doesn't sound reasonable to involve PSF money just for such a psychological issue. But it's not my money anyway ;)
Regards
Antoine.
On 3/03/2010 2:11 PM, Antoine Pitrou wrote:
That was also my sentiment. These issues seem to be overestimated, or perceived as a lack of care for the Windows platform.
This perception is wrong, I do care as much as others about the Windows platform.
That is not my perception. My perception is that non-windows users are underestimating the practical issues involved in having non-native line endings. This is why I think it would be useful for *everyone* commenting here to actually try working with a non-native repo on their platform doing "real" work (eg, applying patches, mailing diffs, etc)
It's just that having to manually run a script from time to time if your editor screws up is not a big deal. I have to do it myself, when SVN refuses my commit and tells me to run Tools/reindent.py.
Agreed - SVN users also have the same issue when a mixed EOL checkin is attempted.
The difference with HG is that the error will not happen at commit time, but rather at *push* time - after the local repo is already in a bad state. We could suggest all Windows users configure HG to run the same hooks locally, but I believe that will quickly become a burden.
To use your analogy: it would be similar to SVN issuing that message *after* accepting the checkin and forcing you to either re-commit a fix, or somehow revert the state of the repo to before the checkin, then re-doing it.
Cheers,
Mark
Le Wed, 03 Mar 2010 14:34:41 +1100, Mark Hammond <mhammond@skippinet.com.au> a écrit :
The difference with HG is that the error will not happen at commit time, but rather at *push* time - after the local repo is already in a bad state. We could suggest all Windows users configure HG to run the same hooks locally, but I believe that will quickly become a burden.
I don't think it will be a burden. After all the current plan is for everybody to configure and enable the EOL extension, IIUC.
Also, I'm not so worried about repository purity, but perhaps it's just me. We do have some "typo fix" or "sorry, I broke the buildbots" commits from time to time...
Regards
Antoine.
Dirkjan Ochtman wrote:
It's perceived as not much of an issue, AFAICT, because people feel that using good editors will save you most of the time, pre-push hooks will prevent everyone from actually polluting the central repository, and it would be easy to install pre-commit hooks locally to get an early warning. ISTM that the remaining problem space is a high level of automation that some Windows developers desire, that they got from SVN, but that is quite small because there's a bunch of mitigating factors. It's perceived as a regression, and as making Windows developers second class because most of the issues won't come up on other systems.
Dirkjan's reasoning here is correct. However, we may be at the point where we've reached diminishing returns on letting this prevent the changeover - perhaps it is time to force the issue by actually switching the development process, documenting the use of the hg-eol extension for anyone that needs it and continuing on from there.
If it turns out nobody on Windows runs into EOL issues and our concerns were unfounded, then so be it - I'm not going to complain about prompting the development of an extension that brings hg's EOL handling up to par with SVN's, as I'm sure we'll be far from the last group of developers that are interested in a DVCS but want that control over EOL handling.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Dirkjan's reasoning here is correct. However, we may be at the point where we've reached diminishing returns on letting this prevent the changeover - perhaps it is time to force the issue by actually switching the development process, documenting the use of the hg-eol extension for anyone that needs it and continuing on from there.
The risk, of course, is to lose Mark Hammond as a contributor.
Regards, Martin
On Tue, Mar 2, 2010 at 5:12 PM, Steve Holden <steve@holdenweb.com> wrote:
Antoine Pitrou wrote:
Le Tue, 02 Mar 2010 10:29:13 -0500, Steve Holden <steve@holdenweb.com> a écrit :
IMHO we got in this mess because we didn't have sufficient involvement from Windows platform users during the DVCS evaluation - people saw that there was some accommodation to Windows, and assumed it would be sufficient for our purposes. It wasn't, and a year later we are only just approaching a solution.
It's still unclear that it's not sufficient, though. To me it seems more like a case of striving for perfection while the current situation should be good enough. In other words, I'm not willing to spend any of my time on what looks to me like a non-issue.
And does it look like a non-issue because you are familiar with the Windows environment or because your imagination can't conceive of why it would be a real problem?
I use HG and do lots of tinkering on Windows, and my imagination can't conceive why this would be a real problem -- unless people chose to make it into one.
(yeah, you sometimes need to run fromdos or equivalent on new files if checking in from windows, and it's nice to have pre-commit filters that complains if you forget, but that's not really a big deal if you factor in all the advantages you get from mercurial...)
</F>
On 3/03/2010 2:29 AM, Steve Holden wrote:
Antoine Pitrou wrote:
Le Tue, 2 Mar 2010 15:41:45 +0100, Dirkjan Ochtman<dirkjan@ochtman.nl> a écrit :
For the EOL issue, there is code, it needs testing. Martin Geisler (the primary author so far) and I issued a call for testing on python-dev last week, but without any response so far.
While I've done testing in the past, I haven't had a chance to do more since last week when it was indicated some of the bugs have been removed and it is now reasonable to test again. It seems unlikely I will find more testing time before next week (and it seems a little unreasonable to assume people can do these kinds of things with only one weeks notice when it has taken many months to get to the point where more testing is possible)
The people who have voiced their annoyance at the EOL situation should do the testing, really.
"Annoyance" isn't really the right word here - there was general agreement that we didn't want to accept 'regressions' over what SVN offers, and combined with the practical issues involved in using incorrect line-endings it seems reasonable to keep pushing for it.
It might be worth reminding people again that this can be tested effectively on platforms other than Windows. Alternatively, if people think there are no practical problems involved and I'm just whining, we could look at converting the repo using \r\n line endings and let non-windows users experience the lack of problems it would cause <wink>.
I expended a good deal of effort last year making sure that core developers who required them got MSDN licenses. This should surely enable some testing. If nobody wants to test for the Windows platform then all the work is going to fall on MvL, who surely has plenty to do without that additional load.
As above - while we obviously want people on Windows to test, it can be tested on any platform - particularly if people are willing to create a test repo with \r\n native line endings. People in this community regularly help design and debug issues which have no direct impact on their day-to-day work - which is obviously a good thing - and hopefully some are willing to help do that in this case too.
While suggesting we use \r\n line endings on the real repo is tongue-in-cheek, maybe we could provide a 'sandbox' copy of the Python repository with \r\n line endings to help spread the testing?
On a more practical note: Without native line-endings in hg, how would Windows binary distributions ship .py files? Would it ship with \n line endings (and therefore potentially confuse *users* of Python as well as developers) or would there be a conversion process (meaning a hg tree would be quite different than a binary tree even though the actual content is identical)?
IMHO we got in this mess because we didn't have sufficient involvement from Windows platform users during the DVCS evaluation - people saw that there was some accommodation to Windows, and assumed it would be sufficient for our purposes. It wasn't, and a year later we are only just approaching a solution.
I don't think that is correct. Let's say we did identity those problems during the DVCS evaluation - how would the outcome have been affected? At the time, bzr had zero support for end-of-line support, so selecting bzr wouldn't have been an outcome. The only outcome I could see would have been to choose to defer the process until one of the DVCS tools under consideration offers the support we need - which, in practice, is where we are today.
Cheers,
Mark
On Tue, 02 Mar 2010 15:41:45 +0100, Dirkjan Ochtman <dirkjan@ochtman.nl> wrote:
On Tue, Mar 2, 2010 at 15:17, Barry Warsaw <barry@python.org> wrote:
We really need to move to a dvcs for development sooner rather than later. It's been a year since the decision was made. I understand that it will suck for Windows developers in the short term, but with all the discussion about the PSF paying for pdo infrastructure work, I think getting us off of Subversion would have the most immediate positive impact for development of Python. If the EOL issue is the holdup, what can we do *right now* to break that logjam? Can't the PSF pay somebody to make this happen?
For the EOL issue, there is code, it needs testing. Martin Geisler (the primary author so far) and I issued a call for testing on python-dev last week, but without any response so far. As for paying someone, I have a full-time job already, so I don't really have the time to do consulting. I could ask around for other Mercurial team members, but I'm not sure there's much point to it if no one is testing the extension that exists right now.
If I understand correctly, the goal was for the extension to be run by all developers, whether they were on windows or not. I think we should make a first cut at the instructions for getting set up to use hg for Python development, including setting up the extension. With those instructions in hand I'll at least test it on my linux box, and I should also be able to find time to test it on a Windows box as well.
--David
I've also asked Brian Curtain to test the extension and he said he would. (He's been doing bug triage, and testing and writing a bunch of windows patches...I think he should be considered for commit access in the not too distant future.)
--David
We really need to move to a dvcs for development sooner rather than later. It's been a year since the decision was made. I understand that it will suck for Windows developers in the short term, but with all the discussion about the PSF paying for pdo infrastructure work, I think getting us off of Subversion would have the most immediate positive impact for development of Python. If the EOL issue is the holdup, what can we do *right now* to break that logjam? Can't the PSF pay somebody to make this happen?
IIUC, it's not just the EOL issue. There are tons of other things to be done, and nobody willing to do them - everybody just wants them to be done.
So people who want the Mercurial switch to happen now really need to step forward and volunteer to work on it, or else it won't happen for another year.
Regards, Martin
On Tue, Mar 2, 2010 at 22:51, "Martin v. Löwis" <martin@v.loewis.de> wrote:
IIUC, it's not just the EOL issue. There are tons of other things to be done, and nobody willing to do them - everybody just wants them to be done.
I wouldn't say there are tons of things, but yes, even if we decided to punt on the whole EOL thing for now, that probably wouldn't bring the switch much closer unless there's also a bunch of people jumping in helping out with other things (some of which are going to be hard -- for example, hacking on hgsubversion if you have no prior experience with that tool). I'm happy to do these things and I think the early May deadline is somewhat realistic, assuming that I don't have to spend much of my time on the EOL issues.
Cheers,
Dirkjan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/03/2010 08:13 AM, Dirkjan Ochtman wrote:
I wouldn't say there are tons of things, but yes, even if we decided to punt on the whole EOL thing for now, that probably wouldn't bring the switch much closer unless there's also a bunch of people jumping in helping out with other things (some of which are going to be hard -- for example, hacking on hgsubversion if you have no prior experience with that tool). I'm happy to do these things and I think the early May deadline is somewhat realistic, assuming that I don't have to spend much of my time on the EOL issues.
Do you have a list of -detailed- pending issues?. Detailed enough to decide if we can help or not...
Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQCVAwUBS45E/Zlgi5GaxT1NAQKLvQQAocR3j76kadnJnd3GpeIR2SjboZUqdn+x 7MmVBBcNXnrE64/5VO3qcS/LvmBN2I1rM1vkdyfFXplmoPZSnyXCKqF5BRM2zUdr W9WdcDmovFQk8W3SAXBp5aCfu+dSBWD9ZtWe7uHhl+lq6RA8R6iTjgVQwFrsQVaZ ksmpFR1xcm8= =JIP7 -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/02/2010 02:21 PM, A.M. Kuchling wrote:
On Tue, Mar 02, 2010 at 04:36:42AM +0100, Jesus Cea wrote:
I can't wait for HG. I have read the main cutprit for the delay is the line-ending issue with MS Windows developers. Is there anything else holding us back?.
Note that, if you'd just like to use Mercurial for your own convenience while developing, the mirrored repositories at http://hg.python.org/ are up-to-date; you just can't push changes back. I have a regex patch that was developed using an hg checkout of the Python source tree, with my changes layered atop it using the mq extension.
This is a really excellent suggestion, and the perfect excuse to get familiar with MQ, that I haven't tried yet.
I have a strange error:
""" [jcea@babylon5 home]$ hg clone http://hg.python.org/cpython/ destination directory: cpython requesting all changes abort: HTTP Error 414: Request-URI Too Large """
Using an sniffer, I see the request is actually huge. I am using Mercurial 1.5.
I can pull individual branches, with "-b" flag (http://hg.python.org/cpython/branches), but I have the same issue doing a "pull" later.
It is not possible to download the full repository?. I could update the clone branch by branch, but must be a better way...
Suggestions?.
Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQCVAwUBS5cAMZlgi5GaxT1NAQLHQgP/S+zDTF/hohMVIjk0bwnh6PyPD7toJ1zy y3g7QOHdd6+HIDIcmMyRSTV6l+vG6h/N0pQEyK7H+zo+PpViRB7P3+7k30qKjz8d HADgJn2Z46l9ajiejfsTDN0aJWK/TkT9NqGHSzgN3zCYbd27lGMoDJo2CkGYn69x zyLgxgy0P1Y= =4l6z -----END PGP SIGNATURE-----
On Wed, Mar 10, 2010 at 03:13, Jesus Cea <jcea@jcea.es> wrote:
This is a really excellent suggestion, and the perfect excuse to get familiar with MQ, that I haven't tried yet.
I have a strange error:
""" [jcea@babylon5 home]$ hg clone http://hg.python.org/cpython/ destination directory: cpython requesting all changes abort: HTTP Error 414: Request-URI Too Large """
Using an sniffer, I see the request is actually huge. I am using Mercurial 1.5.
I can pull individual branches, with "-b" flag (http://hg.python.org/cpython/branches), but I have the same issue doing a "pull" later.
It is not possible to download the full repository?. I could update the clone branch by branch, but must be a better way...
Suggestions?.
Yes, so, this is the result of me not having fully processed the repository yet to prune or merge some branches. (We're also treating it as a bug that we'd like to get fixed in 1.6, but protocol changes aren't very easy due to backwards compatibility concerns.)
So, in the meantime, if you have ssh access, make your clone via ssh. Otherwise, clone a single branch, like this: http://hg.python.org/cpython#py3k, and that should prevent you from getting the error even on subsequent pulls.
Cheers,
Dirkjan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/10/2010 08:29 AM, Dirkjan Ochtman wrote:
So, in the meantime, if you have ssh access, make your clone via ssh.
Could you possibly the exact command to use to clone cpython HG repository?. I can't find it via Google.
Otherwise, clone a single branch, like this: http://hg.python.org/cpython#py3k, and that should prevent you from getting the error even on subsequent pulls.
I tried this, but I get the error again, unless I do a "pull" for that branch only. A "pull" with no options gives the error.
Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQCVAwUBS5e7HJlgi5GaxT1NAQJWsAP/UrG2VD8rP9CabQNMjLrB7VliKg5WxPSL zIAxofaN7r8wJa8m40NlP2VjiXVJnNSJxCzTpDLtgPZwYb017WwkPoZkfAlcyNoZ YqLVKXxQEfGE2COU1CmOonnsMxD8cR0lhhOOdgNG9XzLxCiDjn4x9UgVc2e0Gxhj w9NeC8obv+8= =4PRw -----END PGP SIGNATURE-----
On Mar 10, 2010, at 04:30 PM, Jesus Cea wrote:
Could you possibly the exact command to use to clone cpython HG repository?. I can't find it via Google.
Why not create this page and fill in the details there?
http://wiki.python.org/moin/Mercurial
-Barry
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/10/2010 04:30 PM, Jesus Cea wrote:
On 03/10/2010 08:29 AM, Dirkjan Ochtman wrote:
So, in the meantime, if you have ssh access, make your clone via ssh.
Could you possibly the exact command to use to clone cpython HG repository?. I can't find it via Google.
I still don't know how I can clone the cpython repository. Regular clone doesn't work with current repository state. Dirkjan commented about cloning via SSH, and I have a SSH commit key, but I don't know what command to use...
Help!.
Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQCVAwUBS5rKNplgi5GaxT1NAQLO5gQAiSlee/YxwkVwH5rvNeBHdYMyQgoINI3C SY49GZnZo0e9+IV1zGQBo+tRuqUo71+0P/ehLDnUKqldqOxMLJqHPUfQSxiiGaF+ KH/ol7zZgvnkjTxFc5QvpDbBOuga9Rg1Fdp+jDFM+b0DM3bzmvGEKfcacuqNWpQ1 1afGGATOf0g= =Iv6y -----END PGP SIGNATURE-----
Le Sat, 13 Mar 2010 00:11:51 +0100, Jesus Cea <jcea@jcea.es> a écrit :
I still don't know how I can clone the cpython repository. Regular clone doesn't work with current repository state.
If you don't need to push back to the Mercurial repositories, you can use the "other" mirrors at http://code.python.org/hg
(e.g.: hg clone http://code.python.org/hg/trunk/)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/13/2010 04:01 AM, Antoine Pitrou wrote:
Le Sat, 13 Mar 2010 00:11:51 +0100, Jesus Cea <jcea@jcea.es> a écrit :
I still don't know how I can clone the cpython repository. Regular clone doesn't work with current repository state.
If you don't need to push back to the Mercurial repositories, you can use the "other" mirrors at http://code.python.org/hg
(e.g.:
hg clone http://code.python.org/hg/trunk/)
Thanks, Antoine. Those "mirrors" are not equivalent because they keep different branches in different repositories (compared with the single repository with named branches inside, in the "official" HG), but they are good enough. Thanks. In fact I am not sure this approach is even better, if the respositories share a common parent, so you can move patches around.
Now I have to master the MQ extension :).
Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQCVAwUBS5sLe5lgi5GaxT1NAQJmCwP+NVbcbHDJe16agGMFOm5UobViN9dY9Hvo EuwMm9BdRrijaHRLlbdzQes+RRr1IQ0pf3rpySFXFWS2xVZ87/5/nmBU9CT3KcY9 C9GktBtpwfbiw+dw6IHyH2HxVf+uVytvn8pToDLdPEsp5g1SSYp3AJj7bBeQgM7Q vU40jdXi9QA= =ou4n -----END PGP SIGNATURE-----
On Sat, Mar 13, 2010 at 00:11, Jesus Cea <jcea@jcea.es> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/10/2010 04:30 PM, Jesus Cea wrote:
On 03/10/2010 08:29 AM, Dirkjan Ochtman wrote:
So, in the meantime, if you have ssh access, make your clone via ssh.
Could you possibly the exact command to use to clone cpython HG repository?. I can't find it via Google.
I still don't know how I can clone the cpython repository. Regular clone doesn't work with current repository state. Dirkjan commented about cloning via SSH, and I have a SSH commit key, but I don't know what command to use...
You can clone from ssh://hg@hg.python.org/repos/cpython.
I know, I need to write docs.
Cheers,
Dirkjan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/03/10 03:13, Jesus Cea wrote:
On 03/02/2010 02:21 PM, A.M. Kuchling wrote:
On Tue, Mar 02, 2010 at 04:36:42AM +0100, Jesus Cea wrote:
I can't wait for HG. I have read the main cutprit for the delay is the line-ending issue with MS Windows developers. Is there anything else holding us back?.
Note that, if you'd just like to use Mercurial for your own convenience while developing, the mirrored repositories at http://hg.python.org/ are up-to-date; you just can't push changes back. I have a regex patch that was developed using an hg checkout of the Python source tree, with my changes layered atop it using the mq extension.
This is a really excellent suggestion, and the perfect excuse to get familiar with MQ, that I haven't tried yet.
I have a strange error:
""" [jcea@babylon5 home]$ hg clone http://hg.python.org/cpython/ destination directory: cpython requesting all changes abort: HTTP Error 414: Request-URI Too Large """
Two months later...
I can confirm I can clone now http://hg.python.org/cpython/ , using the new Mercurial 1.5.2. If the repository was not overhaulted, this is GOOD.
The repository has 443 heads. Half a gig. Uffffffffffff.
Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQCVAwUBS+GhQ5lgi5GaxT1NAQLT3gP9GcU5Es1fq4vmdyBdVvUjcWnaGqzpmlDy ngm3MxZ+Sp/jIonI6u66Vw/r2astZ4JTDQ1i9g/y6fRGazkOkxnAM4rMkBSxDHVR 2usDRcyjPo0q49p+NQ1UMZNBylJ4Dj/XR2fNjz89zwTSOfAZkQqH85rEOp2v7Igd V6gB7Vp6XOY= =BoKZ -----END PGP SIGNATURE-----
Two months later...
I can confirm I can clone now http://hg.python.org/cpython/ , using the new Mercurial 1.5.2. If the repository was not overhaulted, this is GOOD.
The repository has 443 heads. Half a gig. Uffffffffffff.
For daily work, I suggest you use http://code.python.org/hg instead. It is much more lightweight (a separate repo for each branch) and, since it isn't meant to test the conversion, the changeset IDs won't change.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 05/05/10 18:59, Antoine Pitrou wrote:
Two months later...
I can confirm I can clone now http://hg.python.org/cpython/ , using the new Mercurial 1.5.2. If the repository was not overhaulted, this is GOOD.
The repository has 443 heads. Half a gig. Uffffffffffff.
For daily work, I suggest you use http://code.python.org/hg instead. It is much more lightweight (a separate repo for each branch) and, since it isn't meant to test the conversion, the changeset IDs won't change.
I know. It is what I do daily. I can not pass without Mercurial Queues :). I dream every night with the day I can use Mercurial natively :-pp.
I was just confirming that the "issue" I had with mercurial two months ago (trying to clone a repository with a lot of heads) is solved in HG 1.5.2, just released.
Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQCVAwUBS+Gl45lgi5GaxT1NAQI3YwP/eLqEWUoFdDOP+X+7B/G24nM/gnoXnPQP YumeWpN5/ijxGuBhyACSl1vkRrAzEtJaORWmqeB15pBtIuEigNZc+oS8QdKoH/X7 Y2PgvKmRPCfNCrwR3m6G1fULA6j4KjZns86BOAZOX06dul9RINi5rzR+Zppmtxes oNmGmyAvEls= =ydC5 -----END PGP SIGNATURE-----
2010/3/1 Brett Cannon <brett@python.org>:
On Mon, Mar 1, 2010 at 09:31, Eric Smith <eric@trueblade.com> wrote:
I've been doing it to remind myself of things that need to be merged, or not. And I believe it used to be used by people doing mass-merges, I'm not sure if that is done any more.
Georg and Benjamin used to do it on occasion back when people did not do any primary development in py3k or would just forget because it was not habit yet.
FWIW, I don't worry about 2.6 or 3.1. I think it's of most importance that the trunk and py3k branch stay in sync, so I only block between those too branches.
-- Regards, Benjamin
Am 01.03.2010 23:44, schrieb Benjamin Peterson:
2010/3/1 Brett Cannon <brett@python.org>:
On Mon, Mar 1, 2010 at 09:31, Eric Smith <eric@trueblade.com> wrote:
I've been doing it to remind myself of things that need to be merged, or not. And I believe it used to be used by people doing mass-merges, I'm not sure if that is done any more.
Georg and Benjamin used to do it on occasion back when people did not do any primary development in py3k or would just forget because it was not habit yet.
FWIW, I don't worry about 2.6 or 3.1. I think it's of most importance that the trunk and py3k branch stay in sync, so I only block between those too branches.
I have also given up about 2.6 or 3.1 getting all bugfixes that are made. I do still block my changes, since I mass-merge the others from time to time, instead of merging them one by one.
Georg
On Mon, Mar 1, 2010 at 1:16 AM, Eric Smith <eric@trueblade.com> wrote:
Steven Bethard wrote:
I'm preparing the argparse module for the 2.7 and 3.2 branches. Could someone remind me again what the commit process is? Commit to 2.7 and merge to 3.2? And do we merge with svnmerge.py or svn merge? There's probably a webpage explaining this somewhere, but my Google-fu is failing me right now.
http://www.python.org/dev/faq/#how-do-i-merge-between-branches
Use svnmerge.py. Commit to trunk, then merge to py3k. You'll probably want to block release26-maint and release31-maint.
Thanks, and done in r78576 (trunk) and r78577 (py3k). I also went ahead and blocked the two maintenance releases (in r78578 and r78579). Hopefully everything went smoothly! Let me know if I screwed anything up. =)
Steve
Where did you get that preposterous hypothesis? Did Steve tell you that? --- The Hiphopopotamus
Am 01.03.2010 09:44, schrieb Steven Bethard:
I'm preparing the argparse module for the 2.7 and 3.2 branches. Could someone remind me again what the commit process is? Commit to 2.7 and merge to 3.2? And do we merge with svnmerge.py or svn merge? There's probably a webpage explaining this somewhere, but my Google-fu is failing me right now.
You'll commit to 2.7 and then merge to 3.2. You also should block the original commit in 2.6, and the 3.2 commit in 3.1. svnmerge usage is described in the dev FAQ:
http://www.python.org/dev/faq/#how-do-i-merge-between-branches
About the docs: I see argparse already uses Sphinx, so the format is fine. We usually have only one page per module though; if the total length isn't more than that of e.g. logging (which is one of the larger documents) I'd like to have all-in-one.
Georg
-- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
participants (19)
-
"Martin v. Löwis" -
A.M. Kuchling -
Antoine Pitrou -
Barry Warsaw -
Benjamin Peterson -
Brett Cannon -
Dirkjan Ochtman -
Eric Smith -
Fredrik Lundh -
Georg Brandl -
Gregory P. Smith -
Jesse Noller -
Jesus Cea -
Mark Hammond -
Michael Foord -
Nick Coghlan -
R. David Murray -
Steve Holden -
Steven Bethard