Hello,
My name is Prashant Kumar and I've worked on porting few python
libraries(distutils2, configobj) and I've been looking at the ideas
list for GSoC for a project related to porting.
I came across [1] and found it interesting. It mentions that some
of the work has already been done;
On Mon, 21 Mar 2011 14:07:46 +0900, Stephen J. Turnbull step...@xemacs.org
wrote:
No, at best the DVCS workflow forces the developer on a branch to
merge and test the revisions that will actually be added to the
repository, and perhaps notice system-level anomolies before pushing.
hg does not
On 21/03/2011 1:04 PM, Martin v. Löwis wrote:
Can you please add a summary of this discussion to
the PEP? (also, can you please check in the PEP, and
give it a number?)
OK, I'll check it in once I get a PEP number allocated as per PEP1,
updated to reflect some of the discussions in this
On 21/03/2011 02:49, Éric Araujo wrote:
I have been avoiding hg import because my understanding is that it
defaults to commit, and I don't see that it has any advantage over patch
itself.
“hg import” understands the extended diff format, which patch does not.
(That format has been described a
R. David Murray writes:
On Mon, 21 Mar 2011 14:07:46 +0900, Stephen J. Turnbull
step...@xemacs.org wrote:
No, at best the DVCS workflow forces the developer on a branch to
merge and test the revisions that will actually be added to the
repository, and perhaps notice system-level
My understanding is that svn does not detect fast forwards, only lack
of conflicts, and therefore in case of concurrent development it is
possible that the repository contains a version that never existed in
any developer's workspace.
I can't understand how you draw this conclusion
A further tip in case it helps anyone: hg import (and its mq
counterpart hg qimport) can patch directly from a URL. This
is handy when I want to try out someone's patch directly from
the issue page on bugs.python.org. [Maybe everyone else knew
this, but I found it out by accident!]
Thanks -
Am 21.03.2011 07:37, schrieb Prashant Kumar:
Hello,
My name is Prashant Kumar and I've worked on porting few python
libraries(distutils2, configobj) and I've been looking at the ideas
list for GSoC for a project related to porting.
I came across [1] and found it interesting. It
On Mon, Mar 21, 2011 at 5:16 PM, Mark Hammond mhamm...@skippinet.com.au wrote:
On 21/03/2011 1:04 PM, Martin v. Löwis wrote:
Can you please add a summary of this discussion to
the PEP? (also, can you please check in the PEP, and
give it a number?)
OK, I'll check it in once I get a PEP
[long post ahead, again]
Guido van Rossum, 21.03.2011 03:46:
Thanks for the clarifications. I now have a much better understanding
of what Cython is. But I'm not sold. For one, your attitude about
strict language compatibility worries me when it comes to the stdlib.
Not sure what you mean
This push caught me by surprise too. So, +1 on having a content of
similar effect.
On Sat, Mar 19, 2011 at 07:05:59PM +0100, Georg Brandl wrote:
+1. (Also I don't understand why we'd need permission from an author to
*remove* content.)
And hypothetically, if the author refuses what do we do?
In article 4d871440.2000...@timgolden.me.uk,
Tim Golden m...@timgolden.me.uk wrote:
A further tip in case it helps anyone: hg import (and its mq
counterpart hg qimport) can patch directly from a URL. This
is handy when I want to try out someone's patch directly from
the issue page on
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3/21/2011 10:44 AM, Martin v. Löwis wrote:
My understanding is that svn does not detect fast forwards, only lack
of conflicts, and therefore in case of concurrent development it is
possible that the repository contains a version that never
Stephen It would be possible for the svn-based workflow to require that
Stephen after testing in one's workspace, one does an svn update, and
Stephen if any changes are made to files in the workspace, the whole
Stephen build and test procedure must be repeated. I don't see that
On Mon, Mar 21, 2011 at 7:44 PM, Martin v. Löwis mar...@v.loewis.de wrote:
If you do an svn up, it merges local changes with remote changes;
if that works without conflicts, it tells you what files it merged,
but lets you commit.
Still, in this case, the merge result did exist in the sandbox
On Mon, Mar 21, 2011 at 7:50 PM, Martin v. Löwis mar...@v.loewis.de wrote:
Am 21.03.2011 07:37, schrieb Prashant Kumar:
Hello,
My name is Prashant Kumar and I've worked on porting few python
libraries(distutils2, configobj) and I've been looking at the ideas
list for GSoC for a project
On Mon, Mar 21, 2011 at 9:14 PM, s...@pobox.com wrote:
I believe it runs counter to the professed intention of the switch away from
a centralized version control system, to make it easier for more people to
contribute to Python. It certainly seems harder for this old dog.
I agree it's harder
Nadeem Vawda wrote:
I was wondering what the policy is regarding copyright notices and license
boilerplate text at the top of source files.
I am currently rewriting the bz2 module (see
http://bugs.python.org/issue5863),
splitting the existing Modules/bz2module.c into Modules/_bz2module.c
Martin v. Löwis writes:
My understanding is that svn does not detect fast forwards, only lack
of conflicts, and therefore in case of concurrent development it is
possible that the repository contains a version that never existed in
any developer's workspace.
I can't understand how
On Mon, 21 Mar 2011 04:09:35 +0100
Martin v. Löwis mar...@v.loewis.de wrote:
Since Python 2.5, we maintain two versions of PyArg_ParseTuple:
one outputting int; the other one outputting Py_ssize_t.
The former should have been removed in 3.0, but this was forgotten.
Still, I would like
On 21 March 2011 01:54, Mark Hammond mhamm...@skippinet.com.au wrote:
ie, let's say we are forced to choose between the following 3 options:
* No launcher at all (the status-quo), causing demonstrable breakage in
Windows file associations whenever Python 2.x and Python 3.x scripts exist
on
On Mon, 21 Mar 2011 18:33:00 +0900, Stephen J. Turnbull step...@xemacs.org
wrote:
R. David Murray writes:
On Mon, 21 Mar 2011 14:07:46 +0900, Stephen J. Turnbull
step...@xemacs.org wrote:
No, at best the DVCS workflow forces the developer on a branch to
merge and test the revisions
On Mon, 21 Mar 2011 04:09:35 +0100
Martin v. Löwis mar...@v.loewis.de wrote:
Since Python 2.5, we maintain two versions of PyArg_ParseTuple:
one outputting int; the other one outputting Py_ssize_t.
The former should have been removed in 3.0, but this was forgotten.
Still, I would like
Given the recent discussion about backwards compatibility: what's
the best approach? What warning should be emitted, if any?
(the warning would only be generated if an s# or similar format
was actually encountered - not just if merely PyArg_ParseTuple is
called).
I'd say a
Le lundi 21 mars 2011 à 04:09 +0100, Martin v. Löwis a écrit :
Since Python 2.5, we maintain two versions of PyArg_ParseTuple:
one outputting int; the other one outputting Py_ssize_t.
The former should have been removed in 3.0, but this was forgotten.
Still, I would like people to move
Victor Stinner, 21.03.2011 15:21:
Le lundi 21 mars 2011 à 04:09 +0100, Martin v. Löwis a écrit :
Since Python 2.5, we maintain two versions of PyArg_ParseTuple:
one outputting int; the other one outputting Py_ssize_t.
The former should have been removed in 3.0, but this was forgotten.
Still,
On Mon, 21 Mar 2011 13:20:59 +0100
M.-A. Lemburg m...@egenix.com wrote:
Nadeem Vawda wrote:
I was wondering what the policy is regarding copyright notices and license
boilerplate text at the top of source files.
I am currently rewriting the bz2 module (see
s...@pobox.com writes:
I believe it runs counter to the professed intention of the switch
away from a centralized version control system, to make it easier
for more people to contribute to Python. It certainly seems harder
for this old dog.
Well, you may be an old dog, but you're also
On 03/21/2011 01:34 PM, Stephen J. Turnbull wrote:
Subversion never ever creates versions in the repository that
didn't before exist in some working copy.
John Arbash-Meinel disagrees with you, so I think I'll go with his
opinion
Besides, it's easy to confirm:
# create a repository
On 2011-03-21 14:40, R. David Murray wrote:
On Mon, 21 Mar 2011 18:33:00 +0900, Stephen J. Turnbull
step...@xemacs.org wrote:
R. David Murray writes:
On Mon, 21 Mar 2011 14:07:46 +0900, Stephen J. Turnbull
step...@xemacs.org wrote:
No, at best the DVCS workflow forces the developer on
Given the recent discussion about backwards compatibility: what's
the best approach? What warning should be emitted, if any?
(the warning would only be generated if an s# or similar format
was actually encountered - not just if merely PyArg_ParseTuple is
called).
I'd say a
On Mar 21, 2011, at 06:14 AM, s...@pobox.com wrote:
It, however requires every developer to become facile, if not expert, with
the ins and outs of the Python/Mercurial workflow. This discourages casual
or intermittent contributions. My main contribution to the Python codebase
over the past
Le lundi 21 mars 2011 à 15:35 +0100, Stefan Behnel a écrit :
Victor Stinner, 21.03.2011 15:21:
Le lundi 21 mars 2011 à 04:09 +0100, Martin v. Löwis a écrit :
Since Python 2.5, we maintain two versions of PyArg_ParseTuple:
one outputting int; the other one outputting Py_ssize_t.
The
On Mon, 21 Mar 2011 11:25:31 -0400
Barry Warsaw ba...@python.org wrote:
Does Mercurial have a way of acting like a centralized vcs to the end user,
the way Bazaar does? IOW, if Skip or others were more comfortable with a
centralized workflow (which is entirely valid imo), can they set up
On Mon, 21 Mar 2011 11:24:24 -0400 (EDT)
Eric Smith e...@trueblade.com wrote:
Given the recent discussion about backwards compatibility: what's
the best approach? What warning should be emitted, if any?
(the warning would only be generated if an s# or similar format
was actually
On Mar 21, 2011, at 04:38 PM, Antoine Pitrou wrote:
On Mon, 21 Mar 2011 11:25:31 -0400
Barry Warsaw ba...@python.org wrote:
Does Mercurial have a way of acting like a centralized vcs to the end user,
the way Bazaar does? IOW, if Skip or others were more comfortable with a
centralized
On Mar 20, 2011, at 04:39 PM, Georg Brandl wrote:
On 20.03.2011 16:21, Guido van Rossum wrote:
What is rebase? Why does everyone want it and hate it at the same time?
Basically, rebase is a way to avoid having pointless merge commits on the
same branch.
There's something I don't understand
Victor Stinner, 21.03.2011 16:26:
Le lundi 21 mars 2011 à 15:35 +0100, Stefan Behnel a écrit :
Victor Stinner, 21.03.2011 15:21:
Le lundi 21 mars 2011 à 04:09 +0100, Martin v. Löwis a écrit :
Since Python 2.5, we maintain two versions of PyArg_ParseTuple:
one outputting int; the other one
Thanks for the example, Hrvoje.
Hrvoje This automatic merging often causes people who migrate to a DVCS
Hrvoje to feel that they have to go through an unnecessary extra step
Hrvoje in their workflows. But once you grasp the hole in the svn
Hrvoje workflow, what svn does (and
On Tue, Mar 22, 2011 at 1:20 AM, Barry Warsaw ba...@python.org wrote:
On Mar 20, 2011, at 04:39 PM, Georg Brandl wrote:
On 20.03.2011 16:21, Guido van Rossum wrote:
What is rebase? Why does everyone want it and hate it at the same time?
Basically, rebase is a way to avoid having pointless
Barry Warsaw writes:
Actually, I meant something like 'bzr checkout':
No. Of the DVCSes, only bzr has that.
This would allow individual developers to treat the repository in a
centralized way like they did for svn, but still allowing other
developers to work in a distributed way.
I
On 21 March 2011 16:20, Barry Warsaw ba...@python.org wrote:
It could be that some aspect of the tools causes A and B to not be hidden as
well as they should, so that when looking at the history for example, the fact
that A and B exist is a jarring or annoying artifact that would be better if
On Mon, 21 Mar 2011 12:20:15 -0400
Barry Warsaw ba...@python.org wrote:
On Mar 20, 2011, at 04:39 PM, Georg Brandl wrote:
On 20.03.2011 16:21, Guido van Rossum wrote:
What is rebase? Why does everyone want it and hate it at the same time?
Basically, rebase is a way to avoid having
On Mar 21, 2011, at 8:25 AM, Barry Warsaw wrote:
Does Mercurial have a way of acting like a centralized vcs to the end user,
the way Bazaar does? IOW, if Skip or others were more comfortable with a
centralized workflow (which is entirely valid imo), can they set up their
local workspace to
On Mon, 21 Mar 2011 15:59:51 +0100, Adrian Buehlmann adr...@cadifra.com wrote:
On 2011-03-21 14:40, R. David Murray wrote:
On Mon, 21 Mar 2011 18:33:00 +0900, Stephen J. Turnbull
step...@xemacs.org wrote:
R. David Murray writes:
On Mon, 21 Mar 2011 14:07:46 +0900, Stephen J. Turnbull
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/21/2011 10:55 AM, Stephen J. Turnbull wrote:
s...@pobox.com writes:
I believe it runs counter to the professed intention of the switch
away from a centralized version control system, to make it easier
for more people to contribute to
Stefan Behnel, 21.03.2011 11:58:
Guido van Rossum, 21.03.2011 03:46:
Have you tried replacing selected stdlib modules with their
Cython-optimized equivalents in some of the NumPy/SciPy distros? (E.g.
what about Enthought's Python distros?) Depending on how well that
goes I might warm up to
On Mar 21, 2011, at 01:19 PM, R. David Murray wrote:
So you are worried about the small window between me doing an 'svn up',
seeing no changes, and doing an 'svn ci'? I suppose that is a legitimate
concern, but considering the fact that if the same thing happens in hg,
the only difference is
On 21/03/2011 17:47, Stefan Behnel wrote:
Stefan Behnel, 21.03.2011 11:58:
Guido van Rossum, 21.03.2011 03:46:
Have you tried replacing selected stdlib modules with their
Cython-optimized equivalents in some of the NumPy/SciPy distros? (E.g.
what about Enthought's Python distros?) Depending on
[skipping the whole long discussion]
Cython is meant to compile Python code. A cython version would just be a
pure Python module, usable with all other implementations, but with type
annotations that make it compile to more optimal C code. Type annotations
can be provided in an external file
On Mar 21, 2011, at 06:07 PM, Antoine Pitrou wrote:
On Mon, 21 Mar 2011 12:20:15 -0400
Barry Warsaw ba...@python.org wrote:
On Mar 20, 2011, at 04:39 PM, Georg Brandl wrote:
On 20.03.2011 16:21, Guido van Rossum wrote:
What is rebase? Why does everyone want it and hate it at the same time?
On Mon, Mar 21, 2011 at 8:38 AM, Antoine Pitrou solip...@pitrou.net wrote:
We cannot emulate svnmerge for porting between branches, though - and
I doubt bzr can do it. That's because merges in common DVCSes are based
on the DAG, while svnmerge is a prettily ad-hoc free-form thing.
The
Hello Guys,
I'm interested in participating in the Google Summer of Code this year
and I've been looking at projects in the Wiki, particularly
speed.pypy.org[1] as I'm very interested in the current VM
development. However given my knowledge that project raised several
questions:
1. Up until now
On Mon, 21 Mar 2011 14:29:54 -0400
Barry Warsaw ba...@python.org wrote:
I don't think many hg users advocate rebase, really. AFAICT the
Mercurial developers themselves don't seem to use it (they do use mq,
OTOH).
I guess that begs the question then. ;)
What harm would there be in
On Mon, Mar 21, 2011 at 12:33 PM, DasIch dasdas...@googlemail.com wrote:
Hello Guys,
I'm interested in participating in the Google Summer of Code this year
and I've been looking at projects in the Wiki, particularly
speed.pypy.org[1] as I'm very interested in the current VM
development.
On Mon, 21 Mar 2011 19:33:55 +0100
DasIch dasdas...@googlemail.com wrote:
3. Several benchmarks (at least the Django and Twisted ones) have
dependencies which are not (yet) ported to 3.x and porting those
dependencies during GSoC as part of this project is an unrealistic
goal. Should those
Some remarks below.
On Mon, Mar 21, 2011 at 2:33 PM, DasIch dasdas...@googlemail.com wrote:
Hello Guys,
I'm interested in participating in the Google Summer of Code this year
and I've been looking at projects in the Wiki, particularly
speed.pypy.org[1] as I'm very interested in the current VM
On Mon, Mar 21, 2011 at 2:48 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Mon, 21 Mar 2011 19:33:55 +0100
DasIch dasdas...@googlemail.com wrote:
3. Several benchmarks (at least the Django and Twisted ones) have
dependencies which are not (yet) ported to 3.x and porting those
dependencies
Le lundi 21 mars 2011 à 11:33 -0700, Daniel Stutzbach a écrit :
On Mon, Mar 21, 2011 at 8:38 AM, Antoine Pitrou solip...@pitrou.net
wrote:
We cannot emulate svnmerge for porting between branches,
though - and
I doubt bzr can do it. That's because merges in common
On Sun, Mar 20, 2011 at 9:39 AM, Georg Brandl g.bra...@gmx.net wrote:
Now, hg pull --rebase prevents that by re-basing the A-B history
line onto the latest remote head. After rebasing, the history looks
like this:
... --- X --- C --- D --- E --- A' --- B'
Rebasing also allows you to
Le lundi 21 mars 2011 à 14:51 -0400, Jesse Noller a écrit :
On Mon, Mar 21, 2011 at 2:48 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Mon, 21 Mar 2011 19:33:55 +0100
DasIch dasdas...@googlemail.com wrote:
3. Several benchmarks (at least the Django and Twisted ones) have
dependencies
Antoine Why not reuse the benchmarks in
Antoine http://hg.python.org/benchmarks/ ?
These looks like basically the same benchmarks as the Unladen Swallow folks
put together, right? Is there any value in them as regression tests (maybe
with more elaborate inputs and/or longer runtimes)?
Daniel If every developer's intermediate commits make it into the main
Daniel repository, it's hard to go back to an older revision to test
Daniel something, because many of the older revisions will be broken in
Daniel some way.
This is what I discovered with my trivial doc patch
Le lundi 21 mars 2011 à 14:06 -0500, s...@pobox.com a écrit :
Antoine Why not reuse the benchmarks in
Antoine http://hg.python.org/benchmarks/ ?
These looks like basically the same benchmarks as the Unladen Swallow folks
put together, right?
Yes, it's basically the continuation of their
Is there any value in them as regression tests (maybe with more
elaborate inputs and/or longer runtimes)?
Antoine You mean to check behaviour or to check for performance
Antoine regressions?
Both. Semantic regressions, and secondarily, performance regressions.
I can
On Mon, 21 Mar 2011 14:30:45 -0500
s...@pobox.com wrote:
Is there any value in them as regression tests (maybe with more
elaborate inputs and/or longer runtimes)?
Antoine You mean to check behaviour or to check for performance
Antoine regressions?
Both. Semantic
On Mar 21, 2011, at 11:56 AM, Daniel Stutzbach wrote:
People love it because it's a very powerful tool. People hate it because it
allows you to shoot yourself in the foot.
There's a certain irony in this. The original motivation for version control
was to be a safety rope, to serve as a
On Mon, 21 Mar 2011 12:40:08 -0700
Raymond Hettinger raymond.hettin...@gmail.com wrote:
Now we seem to be advocating a complex, fragile workflow that
is hard to learn, hard to get right, that let's you shoot yourself in
the foot, and that has rebasing/collapsing steps that destroy and
On 21.03.2011 20:40, Raymond Hettinger wrote:
On Mar 21, 2011, at 11:56 AM, Daniel Stutzbach wrote:
People love it because it's a very powerful tool. People hate it because it
allows you to shoot yourself in the foot.
There's a certain irony in this. The original motivation for
Barry Warsaw ba...@python.org writes:
There's something I don't understand about rebase. It seems like most
git and hg users I hear from advocate rebase, while (ISTM) few Bazaar
users do.
I'd like to understand whether that's a cultural thing or whether it's
a byproduct of some aspect of
On 21.03.2011 20:09, s...@pobox.com wrote:
Daniel If every developer's intermediate commits make it into the main
Daniel repository, it's hard to go back to an older revision to test
Daniel something, because many of the older revisions will be broken in
Daniel some way.
On Mar 21, 2011, at 11:56 AM, Daniel Stutzbach wrote:
Keeping the repository clean makes it easier to use a bisection search to
hunt down the introduction of a bug. If every developer's intermediate
commits make it into the main repository, it's hard to go back to an older
revision to test
On Mar 21, 2011, at 08:58 PM, Georg Brandl wrote:
On 21.03.2011 20:09, s...@pobox.com wrote:
Daniel If every developer's intermediate commits make it into the main
Daniel repository, it's hard to go back to an older revision to test
Daniel something, because many of the older
On Mar 22, 2011, at 06:57 AM, Ben Finney wrote:
Barry Warsaw ba...@python.org writes:
There's something I don't understand about rebase. It seems like most
git and hg users I hear from advocate rebase, while (ISTM) few Bazaar
users do.
I'd like to understand whether that's a cultural thing
On Mon, Mar 21, 2011 at 7:48 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Mon, 21 Mar 2011 19:33:55 +0100
DasIch dasdas...@googlemail.com wrote:
3. Several benchmarks (at least the Django and Twisted ones) have
dependencies which are not (yet) ported to 3.x and porting those
dependencies
On Mar 21, 2011, at 07:38 PM, Antoine Pitrou wrote:
On Mon, 21 Mar 2011 14:29:54 -0400
Barry Warsaw ba...@python.org wrote:
I don't think many hg users advocate rebase, really. AFAICT the
Mercurial developers themselves don't seem to use it (they do use mq,
OTOH).
I guess that begs the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/21/2011 04:33 PM, Barry Warsaw wrote:
On Mar 21, 2011, at 07:38 PM, Antoine Pitrou wrote:
On Mon, 21 Mar 2011 14:29:54 -0400
Barry Warsaw ba...@python.org wrote:
I don't think many hg users advocate rebase, really. AFAICT the
Mercurial
Victor Stinner victor.stin...@haypocalc.com writes:
Le lundi 14 mars 2011 à 15:36 -0400, David Bolen a écrit :
Speaking of bbreport, I sometimes use the published page on that site
(http://code.google.com/p/bbreport/wiki/PythonBuildbotReport) to check
over things, but looking at it today, it
On Mon, 21 Mar 2011 16:33:31 -0400
Barry Warsaw ba...@python.org wrote:
Each of those would be
represented by a changeset in my local line of development, and by a side
branch in the mainline DAG once my merge is completed. You might want to dig
into that sideline to see if indeed I addressed
On Mar 18, 2011, at 07:40 PM, Guido van Rossum wrote:
On Fri, Mar 18, 2011 at 7:28 PM, Greg Ewing greg.ew...@canterbury.ac.nz
wrote:
Tres Seaver wrote:
I'm not even sure why you would want __version__ in 99% of modules: in
the ordinary cases, a module's version should be either the Python
On Mar 19, 2011, at 01:51 PM, Antoine Pitrou wrote:
On Fri, 18 Mar 2011 20:12:19 -0700
Toshio Kuratomi a.bad...@gmail.com wrote:
There is a section in PEP8 about __version__ but it serves a slightly
different purpose there:
Version Bookkeeping
If you have to have Subversion, CVS, or
2011/3/21 Raymond Hettinger raymond.hettin...@gmail.com:
On Mar 21, 2011, at 11:56 AM, Daniel Stutzbach wrote:
People love it because it's a very powerful tool. People hate it because it
allows you to shoot yourself in the foot.
There's a certain irony in this. The original motivation
On 2011-03-22, Ben Finney ben+pyt...@benfinney.id.au wrote:
That seems to me the ideal: preserve all revision history for those
cases when some user will care about it, but *present* history cleanly
by default.
Whether adding support in Mercurial or Git for similar
On Mar 21, 2011, at 09:53 PM, Antoine Pitrou wrote:
I'd rather take a look at the final aggregate patch to see if it looks
correct, actually. It's easy to have incremental changes which look
good but lead to a questionable patch in the end. Better to review it
in aggregate, IMO.
I think it would
On Mon, 21 Mar 2011 17:25:05 -0400
Barry Warsaw ba...@python.org wrote:
On Mar 21, 2011, at 09:53 PM, Antoine Pitrou wrote:
I'd rather take a look at the final aggregate patch to see if it looks
correct, actually. It's easy to have incremental changes which look
good but lead to a
On Tue, Mar 22, 2011 at 3:16 AM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
I don't think that is the main source of complexity.
The more difficult and fragile part of the workflows are:
* requiring commits to be cross-linked between branches
* and wanting changesets to be collapsed
ISTM, there has been substantial mission creep from
the workflow described in the PEP. If the current workflow
had been described there, I don't think it would have been
readily accepted.
I don't think PEP 385 actually *was* accepted at all (PEP 374
was, selecting Mercurial). I had meant to
It does so at the *tree* level, not at an individual file level.
Thanks - I stand corrected. I was thinking about the file level only (at
which it doesn't do server-side merging - right?).
Regards,
Martin
___
Python-Dev mailing list
On Mon, Mar 21, 2011 at 2:31 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Mon, 21 Mar 2011 17:25:05 -0400
Barry Warsaw ba...@python.org wrote:
On Mar 21, 2011, at 09:53 PM, Antoine Pitrou wrote:
I'd rather take a look at the final aggregate patch to see if it looks
correct, actually.
On Tue, Mar 22, 2011 at 7:25 AM, Barry Warsaw ba...@python.org wrote:
On Mar 21, 2011, at 09:53 PM, Antoine Pitrou wrote:
I'd rather take a look at the final aggregate patch to see if it looks
correct, actually. It's easy to have incremental changes which look
good but lead to a questionable
On Tue, 22 Mar 2011 07:32:33 +1000
Nick Coghlan ncogh...@gmail.com wrote:
As far as the second point goes, I'm coming to the view that we should
avoid rebase/strip/rollback when intending to push to the main
repository, and do long term work in *separate* cloned repositories.
Then an rdiff
On Mon, 21 Mar 2011 22:47:19 +0100
Martin v. Löwis mar...@v.loewis.de wrote:
ISTM, there has been substantial mission creep from
the workflow described in the PEP. If the current workflow
had been described there, I don't think it would have been
readily accepted.
I don't think PEP
On Tue, Mar 22, 2011 at 7:51 AM, Guido van Rossum gu...@python.org wrote:
Let's say I'm working on a fairly substantial feature that may take
weeks to complete. My way of working is to explore different
approaches until I'm happy. I like to make checkpoints while I'm
exploring so that I can
I don't think that is the main source of complexity.
The more difficult and fragile part of the workflows are:
* requiring commits to be cross-linked between branches
* and wanting changesets to be collapsed or rebased
(two operations that destroy and rewrite history).
I think there
On Mon, Mar 21, 2011 at 3:00 PM, Nick Coghlan ncogh...@gmail.com wrote:
On Tue, Mar 22, 2011 at 7:51 AM, Guido van Rossum gu...@python.org wrote:
Let's say I'm working on a fairly substantial feature that may take
weeks to complete. My way of working is to explore different
approaches until
On Mon, Mar 21, 2011 at 2:20 PM, M.-A. Lemburg m...@egenix.com wrote:
Nadeem Vawda wrote:
[snip]
Since you'll be adding new IP to Python, the new code you write should
contain your copyright and the standard PSF contributor agreement
notice, e.g.
(c) Copyright 2011 by Nadeem Vawda.
I know I would be sorely tempted to use hg export + hg import (and
extensive testing after the latter of course) so that the approved
changes can land with a single thud in the core repo. But maybe I'm a
dinosaur?
I certainly agree that there are cases where collapsing changes is
desirable -
However, what some of us requesting is that the SHOULD collapse
in the devguide is changed to a MAY collapse, making it strictly
an option of the committer. If there is one substantial change,
a typo change, and three merges, asking for a collapse of the typo
change is IMO complicating
One of the key elements here is the way we use python-checkins for
after-the-fact review.
I think this can be achieved with a better email hook. I would propose
that there will be one email message per push per branch (rather than
one per changeset). For each branch, it should report what
On Mon, Mar 21, 2011 at 2:24 PM, DasIch dasdas...@googlemail.com wrote:
On Mon, Mar 21, 2011 at 7:48 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Mon, 21 Mar 2011 19:33:55 +0100
DasIch dasdas...@googlemail.com wrote:
3. Several benchmarks (at least the Django and Twisted ones) have
1 - 100 of 105 matches
Mail list logo
