On Mon, 21 Mar 2011 14:07:46 +0900, "Stephen J. Turnbull"
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 force the dev
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 th
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"
> 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 bef
> 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 ("the
> 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!]
Thank
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.
On Mon, Mar 21, 2011 at 5:16 PM, Mark Hammond 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 number allocated
[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 exac
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 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 bugs.python.org. [Maybe
-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 neve
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" 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
> of the dev
On Mon, Mar 21, 2011 at 7:50 PM, "Martin v. Löwis" 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 related t
On Mon, Mar 21, 2011 at 9:14 PM, 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 *now*, but
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/_bz2modul
"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 und
On Mon, 21 Mar 2011 04:09:35 +0100
"Martin v. Löwis" 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 people to move
On 21 March 2011 01:54, Mark Hammond 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 the same box.
>
> * An
On Mon, 21 Mar 2011 18:33:00 +0900, "Stephen J. Turnbull"
wrote:
> R. David Murray writes:
> > On Mon, 21 Mar 2011 14:07:46 +0900, "Stephen J. Turnbull"
> wrote:
> > > No, at best the DVCS workflow forces the developer on a branch to
> > > merge and test the revisions that will actually be a
> On Mon, 21 Mar 2011 04:09:35 +0100
> "Martin v. Löwis" 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 people
>
> >> 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).
> >
>
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 m
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" 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
> > http://bugs.python.org/issue586
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 als
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"
> wrote:
>> R. David Murray writes:
>> > On Mon, 21 Mar 2011 14:07:46 +0900, "Stephen J. Turnbull"
>> wrote:
>> > > No, at best the DVCS workflow forces the developer on a branch to
>> > >
>>
>> >> 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).
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 c
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.
>
On Mon, 21 Mar 2011 11:25:31 -0400
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 wo
On Mon, 21 Mar 2011 11:24:24 -0400 (EDT)
"Eric Smith" 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 actual
On Mar 21, 2011, at 04:38 PM, Antoine Pitrou wrote:
>On Mon, 21 Mar 2011 11:25:31 -0400
>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 (whi
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 underst
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 ou
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 (an
On Tue, Mar 22, 2011 at 1:20 AM, Barry Warsaw 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 merge co
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 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
> they didn't e
On Mon, 21 Mar 2011 12:20:15 -0400
Barry Warsaw 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 m
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 workspac
On Mon, 21 Mar 2011 15:59:51 +0100, Adrian Buehlmann wrote:
> On 2011-03-21 14:40, R. David Murray wrote:
> > On Mon, 21 Mar 2011 18:33:00 +0900, "Stephen J. Turnbull"
> > wrote:
> >> R. David Murray writes:
> >> > On Mon, 21 Mar 2011 14:07:46 +0900, "Stephen J. Turnbull"
> >> wrote:
> >> >
-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 contri
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 Cytho
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 externa
On Mar 21, 2011, at 06:07 PM, Antoine Pitrou wrote:
>On Mon, 21 Mar 2011 12:20:15 -0400
>Barry Warsaw 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 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 equivalent way to how
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 t
On Mon, 21 Mar 2011 14:29:54 -0400
Barry Warsaw 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 relaxing
On Mon, Mar 21, 2011 at 12:33 PM, DasIch 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. However given my knowledg
On Mon, 21 Mar 2011 19:33:55 +0100
DasIch 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 benchmarks, at least
Some remarks below.
On Mon, Mar 21, 2011 at 2:33 PM, DasIch 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. Howev
On Mon, Mar 21, 2011 at 2:48 PM, Antoine Pitrou wrote:
> On Mon, 21 Mar 2011 19:33:55 +0100
> DasIch 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 proje
Le lundi 21 mars 2011 à 11:33 -0700, Daniel Stutzbach a écrit :
> On Mon, Mar 21, 2011 at 8:38 AM, Antoine Pitrou
> wrote:
> We cannot emulate "svnmerge" for porting between branches,
> though - and
> I doubt bzr can do it. That's because merges in common DVCSes
> a
On Sun, Mar 20, 2011 at 9:39 AM, Georg Brandl 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 collapse the
Le lundi 21 mars 2011 à 14:51 -0400, Jesse Noller a écrit :
> On Mon, Mar 21, 2011 at 2:48 PM, Antoine Pitrou wrote:
> > On Mon, 21 Mar 2011 19:33:55 +0100
> > DasIch wrote:
> >>
> >> 3. Several benchmarks (at least the Django and Twisted ones) have
> >> dependencies which are not (yet) ported to
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 pa
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
>> 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 unde
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. S
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
On Mon, 21 Mar 2011 12:40:08 -0700
Raymond Hettinger 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
> rewrite history (an possibl
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
Barry Warsaw 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 the respectiv
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 w
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 s
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 th
On Mar 22, 2011, at 06:57 AM, Ben Finney wrote:
>Barry Warsaw 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 wh
On Mon, Mar 21, 2011 at 7:48 PM, Antoine Pitrou wrote:
> On Mon, 21 Mar 2011 19:33:55 +0100
> DasIch 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 proje
On Mar 21, 2011, at 07:38 PM, Antoine Pitrou wrote:
>On Mon, 21 Mar 2011 14:29:54 -0400
>Barry Warsaw 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 q
-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 wrote:
I don't think many hg users advocate rebase, really. AFAICT the
Mercurial
Victor Stinner 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 seems to most recen
On Mon, 21 Mar 2011 16:33:31 -0400
Barry Warsaw 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 the issues i
On Mar 18, 2011, at 07:40 PM, Guido van Rossum wrote:
>On Fri, Mar 18, 2011 at 7:28 PM, Greg Ewing
>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
>>> version (for
On Mar 19, 2011, at 01:51 PM, Antoine Pitrou wrote:
>On Fri, 18 Mar 2011 20:12:19 -0700
>Toshio Kuratomi 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 :
>
> 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
>
On 2011-03-22, Ben Finney 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
> clean-presentation-by-default would obviate th
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 wo
On Mon, 21 Mar 2011 17:25:05 -0400
Barry Warsaw 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 patch
On Tue, Mar 22, 2011 at 3:16 AM, Raymond Hettinger
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 or rebased
> (two oper
> 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
> 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
Python-Dev@python.
On Mon, Mar 21, 2011 at 2:31 PM, Antoine Pitrou wrote:
> On Mon, 21 Mar 2011 17:25:05 -0400
> Barry Warsaw 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 increment
On Tue, Mar 22, 2011 at 7:25 AM, Barry Warsaw 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 patch in the
On Tue, 22 Mar 2011 07:32:33 +1000
Nick Coghlan 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 with the releva
On Mon, 21 Mar 2011 22:47:19 +0100
"Martin v. Löwis" 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 385 actua
On Tue, Mar 22, 2011 at 7:51 AM, Guido van Rossum 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 easily backtrac
> 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 wrote:
> On Tue, Mar 22, 2011 at 7:51 AM, Guido van Rossum 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 chec
On Mon, Mar 21, 2011 at 2:20 PM, M.-A. Lemburg 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. Licensed
> 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 complicati
> 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 chan
On Mon, Mar 21, 2011 at 2:24 PM, DasIch wrote:
> On Mon, Mar 21, 2011 at 7:48 PM, Antoine Pitrou wrote:
>> On Mon, 21 Mar 2011 19:33:55 +0100
>> DasIch wrote:
>>>
>>> 3. Several benchmarks (at least the Django and Twisted ones) have
>>> dependencies which are not (yet) ported to 3.x and porting
On 22/03/2011 12:04 AM, Paul Moore wrote:
I haven't had time to read the PEP yet, so my apologies if this is
made explicit there, but is the launcher expected to be solely for
implementing file associations? I thought there had been discussions
of using it to start the interactive interpreter, an
1 - 100 of 140 matches
Mail list logo
