Re: [Python-Dev] More detailed build instructions for Windows

2010-07-03 Thread Martin v. Löwis 
> I'm trying to test out a patch to add a timeout in subprocess.py on
> Windows, so I need to build Python with Visual Studio.  The docs say
> the files in PCBuild/ work with VC 9 and newer.

Which docs did you look at specifically that said "and newer"? That
would be a bug.

> I downloaded Visual
> C++ 2010 Express, and it needs to convert the .vcproj files into
> .vcxproj files, but it fails.

Please take a look at PCbuild/readme.txt. It tells you to install
one of the Visual Studio 2008 editions.

Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Let's get you ready for Mercurial migration!

2010-07-03 Thread Stephen J. Turnbull 
Steve Holden writes:

 > If the wave were to result in good documentation about how to *get*
 > ready that would be an amazingly useful contribution.

I'm a coauthor of PEP 374 and of http://emacswiki.org/BzrForEmacsDevs.

I think that I can have a document adapted from the Python dev FAQ,
possibly integrating parts of BzrForEmacsDevs (style, ideas, not
literal commands of course -- sorry, Barry) and the hginit.com
tutorial (assuming it's free enough, will check) by July 21.

If anybody thinks they'd do a better job, or simply that I'm not
appropriate, let me know (I have a thick skin and plenty of other work
to do :-).  If it sounds like a good idea, let me know where and how
to submit (patch to dev FAQ on the tracker is the default).

Of course, collaborators welcome, mail me off list.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] blocking 2.7

2010-07-03 Thread Mark Dickinson 
On Sat, Jul 3, 2010 at 4:28 AM, Benjamin Peterson  wrote:
> This is just a note that we have one bug blocking 2.7 final at the
> moment: http://bugs.python.org/issue9144

I've just made http://bugs.python.org/issue7673 a release blocker too,
I'm afraid.  It's a potential security vulnerability in the audioop
module.  (CVE-2010-2089).  It's got a reviewed patch, and is ready to
be committed, but if you're not comfortable with fixing it this late
then that's completely understandable.

Mark
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] blocking 2.7

2010-07-03 Thread Antoine Pitrou 
On Sat, 3 Jul 2010 11:17:16 +0100
Mark Dickinson  wrote:
> On Sat, Jul 3, 2010 at 4:28 AM, Benjamin Peterson  wrote:
> > This is just a note that we have one bug blocking 2.7 final at the
> > moment: http://bugs.python.org/issue9144
> 
> I've just made http://bugs.python.org/issue7673 a release blocker too,
> I'm afraid.  It's a potential security vulnerability in the audioop
> module.  (CVE-2010-2089).  It's got a reviewed patch, and is ready to
> be committed, but if you're not comfortable with fixing it this late
> then that's completely understandable.

Interestingly, Victor filed both the issue and the initial patch five
months before the CVE alert. Well done Victor!



___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] SVN <-> HG workflow to split Python Library by Module

2010-07-03 Thread Stephen J. Turnbull 
Brett Cannon writes:

 > Mercurial has subrepo support, but that doesn't justify the need to
 > have every module in its own repository so they can be checked out
 > individually.

The point of submodules a la git is subtly different.  It is that you
can mix and match *known versions* of the modules.  So, eg, in order
to work on recent urllib, maybe you need a recent *but stable* email
but you don't want any of the work being done on removing the GIL
because it's somewhat unstable.

Of course it doesn't guarantee that your choice will actually work.
The point is to make it (a) convenient to explore and (b) easy to
exactly reproduce a successful configuration.

More or less David C's reply but with a different slant.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] SVN <-> HG workflow to split Python Library by Module

2010-07-03 Thread Dirkjan Ochtman 
On Sat, Jul 3, 2010 at 12:53, Stephen J. Turnbull  wrote:
> The point of submodules a la git is subtly different.  It is that you
> can mix and match *known versions* of the modules.  So, eg, in order
> to work on recent urllib, maybe you need a recent *but stable* email
> but you don't want any of the work being done on removing the GIL
> because it's somewhat unstable.

This sounds like it could also be done with good branching + merging.

Cheers,

Dirkjan
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] blocking 2.7

2010-07-03 Thread Victor Stinner 
Le samedi 03 juillet 2010 12:17:16, Mark Dickinson a écrit :
> On Sat, Jul 3, 2010 at 4:28 AM, Benjamin Peterson  
wrote:
> > This is just a note that we have one bug blocking 2.7 final at the
> > moment: http://bugs.python.org/issue9144
> 
> I've just made http://bugs.python.org/issue7673 a release blocker too,
> I'm afraid.  It's a potential security vulnerability in the audioop
> module.  (CVE-2010-2089)

At least, Fedora consider it as a security vulnerability:

   https://bugzilla.redhat.com/show_bug.cgi?id=598197

I agree because the crash is caused by the input data.

> It's got a reviewed patch, and is ready to be committed

Thanks because my first patch was incomplete :-)

> but if you're not comfortable with fixing it this late
> then that's completely understandable.

In the worst case, a function rejects valid data. If I have to choose, I 
prefer to reject valid data than a security vulnerability. But audioop has 
tests and I don't think that my patch breaks anything :-)

-- 
Victor Stinner
http://www.haypocalc.com/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] blocking 2.7

2010-07-03 Thread Jesse Noller 
On Fri, Jul 2, 2010 at 11:40 PM, Nick Coghlan  wrote:
> On Sat, Jul 3, 2010 at 1:28 PM, Benjamin Peterson  wrote:
>> This is just a note that we have one bug blocking 2.7 final at the
>> moment: http://bugs.python.org/issue9144
>
> I added Jesse to the nosy list for that as well.
>
> Cheers,
> Nick.

Committed the patch for 9144 - Brett broke mah imports!
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] SVN <-> HG workflow to split Python Library by Module

2010-07-03 Thread Jesse Noller 
On Sat, Jul 3, 2010 at 7:05 AM, Dirkjan Ochtman  wrote:
> On Sat, Jul 3, 2010 at 12:53, Stephen J. Turnbull  wrote:
>> The point of submodules a la git is subtly different.  It is that you
>> can mix and match *known versions* of the modules.  So, eg, in order
>> to work on recent urllib, maybe you need a recent *but stable* email
>> but you don't want any of the work being done on removing the GIL
>> because it's somewhat unstable.
>
> This sounds like it could also be done with good branching + merging.
>
> Cheers,
>
> Dirkjan

What Dirkjan said; since using mercurial more and more lately, local
branches are an insanely good tool and method of coordinating work
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] blocking 2.7

2010-07-03 Thread Victor Stinner 
Le samedi 03 juillet 2010 14:26:53, Victor Stinner a écrit :
> In the worst case, a function rejects valid data. If I have to choose, I
> prefer to reject valid data than a security vulnerability. But audioop has
> tests and I don't think that my patch breaks anything :-)

I checked the test suite: *all* audioop function are tested at least once.

So, can I / should I commit the patch?

-- 
Victor Stinner
http://www.haypocalc.com/
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] blocking 2.7

2010-07-03 Thread Antoine Pitrou 
On Sat, 3 Jul 2010 14:40:57 +0200
Victor Stinner  wrote:
> Le samedi 03 juillet 2010 14:26:53, Victor Stinner a écrit :
> > In the worst case, a function rejects valid data. If I have to choose, I
> > prefer to reject valid data than a security vulnerability. But audioop has
> > tests and I don't think that my patch breaks anything :-)
> 
> I checked the test suite: *all* audioop function are tested at least once.
> 
> So, can I / should I commit the patch?

In my opinion you can.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] More detailed build instructions for Windows

2010-07-03 Thread Christian Heimes 
Am 03.07.2010 09:00, schrieb "Martin v. Löwis":
>> I'm trying to test out a patch to add a timeout in subprocess.py on
>> Windows, so I need to build Python with Visual Studio.  The docs say
>> the files in PCBuild/ work with VC 9 and newer.
> 
> Which docs did you look at specifically that said "and newer"? That
> would be a bug.

The readme.txt in the PCbuild directory contains the sentence "Microsoft
Visual C++ 2008 Express Edition is required at the very least". The
wording could be interpreted as "2008 at very least" instead of "Express
Edition at very least".

Christian

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] More detailed build instructions for Windows

2010-07-03 Thread Reid Kleckner 
On Sat, Jul 3, 2010 at 12:00 AM, "Martin v. Löwis"  wrote:
>> I'm trying to test out a patch to add a timeout in subprocess.py on
>> Windows, so I need to build Python with Visual Studio.  The docs say
>> the files in PCBuild/ work with VC 9 and newer.
>
> Which docs did you look at specifically that said "and newer"? That
> would be a bug.

On the developer FAQ page it says:
http://www.python.org/dev/faq/#id8
"For VC 9 and newer, the PCbuild directory contains the build files."

But I'll go get 2008.  Thanks!

Reid
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial migration readiness

2010-07-03 Thread Georg Brandl 
Am 03.07.2010 01:54, schrieb "Martin v. Löwis":
>> I don't know about "try" -- personally I don't see a difference for
>> the release procedure, no matter where the source comes from.
> 
> I guess you haven't done a release yet, then :-)

That's possible :)

> Assuming you are going to use
> 
> https://svn.python.org/projects/sandbox/trunk/release/release.py
> 
> then you'll have to port that to Mercurial, first.

True, but it doesn't look too hard.

> Or, you write your own release tool, as any serious release manager did
> so far :-)
> 
> As for the Windows build, I don't know how to do "externals", yet.
> In particular, I don't think it is a good idea to have all externals
> in a single Mercurial clone: due to versioning, we have multiple copies
> of them, which will take quite some space.

True.

> As a minor problem: I currently have a batch file head.bat, which
> updates sysmodule.c after a switch to expand HeadURL correctly.
> Not sure whether this will be needed on Mercurial, or whether the
> build identification patch is able to learn about tags in the first
> place.

I have no solution to that from the top of my head, but it will be dealt
with

> Finally, I wonder how the documentation build process will continue to
> integrate subversion. I guess you just need to have an svn binary around
> when building the documentation.

Since I'm giving specific versions in the makefiles anyway, the easiest
solution would be to put them as tarfiles/zipfiles up for download
somewhere on python.org, and have a small script that gets them via urllib.

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.

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial migration readiness

2010-07-03 Thread Tres Seaver 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Martin v. Löwis wrote:

>> Can somebody comment on how much ongoing effort is required to keep that
>> mirror running?
> 
> As everybody else indicated: none (I believe).

OK, cool.  I have certainly had no issues using it when working as a
non-committer to verify patches, etc., for bugs.python.org issues.

> FWIW, the bzr mirror wasn't that self-maintaining: the process started
> to consume too much memory and got killed; the cron jobs broke, and so
> on, so we finally switched it of (in favor of the Launchpad mirror that
> also existed).

Yup, we saw that to, and have the loggerhead server running under
supervisor, with a configuration to restart it it exceeds a given amount
of RAM.  In our case, the cron jobs to update the mirror were actually
more easier to set up for bzr (and more stable) than for hg or git, but
the hg server was better behaved (the git web bit runs as CGI, IIRC).


Tres.
- --
===
Tres Seaver  +1 540-429-0999  [email protected]
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkwvXGAACgkQ+gerLs4ltQ55kwCgmO5Z1coKDcRUs/n/MvLVfW9t
ul8AmwfnorXyVznEDNyxIX5f2/zNGurI
=TIqB
-END PGP SIGNATURE-

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial migration readiness

2010-07-03 Thread Tres Seaver 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Martin v. Löwis wrote:
> Am 02.07.2010 15:09, schrieb Fred Drake:
>> On Fri, Jul 2, 2010 at 8:34 AM, Antoine Pitrou  wrote:
>>> The two sets of repositories use different conversion tools and rules.
>>> They have nothing in common (different changeset IDs, different
>>> metadata, different branch/clone layout).
>> I'd love to see a more detailed description of this, including why
>> someone new to Mercurial would choose one over the other.
> 
> I think someone new to Mercurial shouldn't choose either one.
> 
> Just sit back and wait for the real migration to happen.

I would say that using the SVN mirror is a fine way to experiment with
using hg against the Python sources to develop and test patches.  Here
is the setup I have used for work against trunk (I have a parallel pair
of repositories for the release2.6-maint branch):

- - Create a "pristine" clone of the trunk (one where I never commit any
  changes):

  $ cd $python_repo
  $ hg clone http://code.python.org/hg/trunk/ pytrunk-upstream

- - Create a local clone from that repository:

  $ hg clone pytrunk-upstream pytrunk-work
  $ ./configure && make

Before working on a patch, I refresh the upstream repository:

  $ cd $python_repo/pytrunk-upstream && hg pull

and pull any changes into the local working repository:

  $ cd $python_repo/pytrunk-work
  $ hg pull -u
  $ make

I make a branch per roundup issue number in the working repository (in
order to avoid needing to rebuild the world for each issue):

  $ cd $python_repo/pytrunk-work
  $ hg branch  issue4265-shutil_copyfile

and then test / tweak the patch on that branch, committing as I go:

  $ patch -p0 < /tmp/shutil_copyfile.patch
  $ hg commit
  $ make
  $ ./python -E -tt -m test.regrtest test_shutil

etc.  If I have tweaked the patch, I can export a new version of the patch:

  $ hg log -p -b issue4265-shutil_copyfile > /tmp/updated_fix.patch

I haven't tried yet, but I imagine I could use 'hg email' to send the
patch as well.

Once the migration is done, of course, users who have been working with
that mirror will need to set up new clones for the upstream and re-clone
the working trees, as the revision IDs won't match, etc.


Tres.
- --
===
Tres Seaver  +1 540-429-0999  [email protected]
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkwvZvgACgkQ+gerLs4ltQ71GACfTw4kNDm+IOv7Jvq8XFtCu6XD
rXoAn3G7i+emGwgp9bxhaHQ+gctIXilA
=am67
-END PGP SIGNATURE-

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] More detailed build instructions for Windows

2010-07-03 Thread Terry Reedy 

On 7/3/2010 10:34 AM, Christian Heimes wrote:


Which docs did you look at specifically that said "and newer"? That
would be a bug.


The readme.txt in the PCbuild directory contains the sentence "Microsoft
Visual C++ 2008 Express Edition is required at the very least". The
wording could be interpreted as "2008 at very least"


That I how I would first read it, not already knowing differently.


instead of "Express Edition at very least".


I did not know that there was anything 'less' than Express Edition. 
Something like "Building Pythonx.y requires at least the Express Edition 
of Visual C++ 2008." or "Building Pyx.y requires Visual C++ 2008. Use 
the free Express Edition or one of its paid upgrades."


--
Terry Jan Reedy

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial migration readiness

2010-07-03 Thread Terry Reedy 

On 7/3/2010 12:36 PM, Tres Seaver wrote:


I would say that using the SVN mirror is a fine way to experiment with
using hg against the Python sources to develop and test patches.  Here
is the setup I have used for work against trunk (I have a parallel pair
of repositories for the release2.6-maint branch):

- - Create a "pristine" clone of the trunk (one where I never commit any
   changes):

   $ cd $python_repo
   $ hg clone http://code.python.org/hg/trunk/ pytrunk-upstream

- - Create a local clone from that repository:

   $ hg clone pytrunk-upstream pytrunk-work
   $ ./configure&&  make

Before working on a patch, I refresh the upstream repository:

   $ cd $python_repo/pytrunk-upstream&&  hg pull

and pull any changes into the local working repository:

   $ cd $python_repo/pytrunk-work
   $ hg pull -u
   $ make


This is perhaps a naive question, but hat do you gain with the 
intermediate mirror clone of upstream? (Other than filling more of your 
disk?)


--
Terry Jan Reedy

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial migration readiness

2010-07-03 Thread Antoine Pitrou 
On Sat, 03 Jul 2010 14:16:08 -0400
Terry Reedy  wrote:
> 
> This is perhaps a naive question, but hat do you gain with the 
> intermediate mirror clone of upstream? (Other than filling more of your 
> disk?)

Filling less of your disk, actually, since local clones use hardlinks.
Also, pulling less data from the network might be interesting if you
have a slow connection, or pull from a very heavy or very active repo
(which CPython isn't, though).

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial migration readiness

2010-07-03 Thread Tres Seaver 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Terry Reedy wrote:

> This is perhaps a naive question, but hat do you gain with the 
> intermediate mirror clone of upstream? (Other than filling more of your 
> disk?)

I gain having my local changes be in a "scratchpad" repsitory, which I
can discard at will without requiring a re-fetch of the whole repository
from the mirror server, which takes a lng time and (apparently) puts
significant load on that server.

As Antoine noted, hg shares the disk space via hard links where
possible;  where not, what's a few hundred megabytes, more or less?


Tres.
- --
===
Tres Seaver  +1 540-429-0999  [email protected]
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkwvjKoACgkQ+gerLs4ltQ7aUgCdHeUOkSTDQYefjih8WMH+OXkL
3E4AoLjk7mtG3E8ayxK1NDMlbkQweIiY
=40ji
-END PGP SIGNATURE-

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial migration readiness

2010-07-03 Thread Daniel Stutzbach 
On Sat, Jul 3, 2010 at 11:36 AM, Tres Seaver  wrote:

> - - Create a "pristine" clone of the trunk (one where I never commit any
>  changes):
>
>  $ cd $python_repo
>  $ hg clone http://code.python.org/hg/trunk/ pytrunk-upstream
>
> - - Create a local clone from that repository:
>
>  $ hg clone pytrunk-upstream pytrunk-work
>  $ ./configure && make
>

My question is basically the same as Terry Reedy's, but I'm going to phrase
it a bit differently:

This is perhaps a naive question, but why do you create a second local clone
instead of just creating a branch?
--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC 
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] More detailed build instructions for Windows

2010-07-03 Thread Martin v. Löwis 
Am 03.07.2010 16:34, schrieb Christian Heimes:
> Am 03.07.2010 09:00, schrieb "Martin v. Löwis":
>>> I'm trying to test out a patch to add a timeout in subprocess.py on
>>> Windows, so I need to build Python with Visual Studio.  The docs say
>>> the files in PCBuild/ work with VC 9 and newer.
>>
>> Which docs did you look at specifically that said "and newer"? That
>> would be a bug.
> 
> The readme.txt in the PCbuild directory contains the sentence "Microsoft
> Visual C++ 2008 Express Edition is required at the very least". The
> wording could be interpreted as "2008 at very least" instead of "Express
> Edition at very least".

That's what I expected to get as an answer - interestingly enough, Reid
was looking at some other place (the FAQ) that literally said "and
newer". I'd call that an error, even though, technically, converting the
projects to VS 2010 "ought to work" (i.e. it did after I committed some
fixes to make it work).

Regards,
Martin


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial migration readiness

2010-07-03 Thread Martin v. Löwis 
>>> I'd love to see a more detailed description of this, including why
>>> someone new to Mercurial would choose one over the other.
> 
>> I think someone new to Mercurial shouldn't choose either one.
> 
>> Just sit back and wait for the real migration to happen.
> 
> I would say that using the SVN mirror is a fine way to experiment with
> using hg against the Python sources to develop and test patches. 

I think your description already falls into the "advanced user"
category. The new-to-mercurial committer should (IMO) use a "what if it
still was svn" workflow, which uses hg pull/up/commit/push. That can
only work if pushing really has the desired effect, which isn't the case
for any of the installations that we operate.

When the test-for-two-weeks installation becomes available, the
new-to-hg users will have a chance to learn how to use it without fear
of breaking anything. Until then, they should just remain patient.

Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial migration readiness

2010-07-03 Thread Antoine Pitrou 
On Sun, 04 Jul 2010 00:51:58 +0200
"Martin v. Löwis"  wrote:
> >>> I'd love to see a more detailed description of this, including why
> >>> someone new to Mercurial would choose one over the other.
> > 
> >> I think someone new to Mercurial shouldn't choose either one.
> > 
> >> Just sit back and wait for the real migration to happen.
> > 
> > I would say that using the SVN mirror is a fine way to experiment with
> > using hg against the Python sources to develop and test patches. 
> 
> I think your description already falls into the "advanced user"
> category. The new-to-mercurial committer should (IMO) use a "what if it
> still was svn" workflow, which uses hg pull/up/commit/push.

This assumes they are accustomed to SVN. I guess not all people are,
although it is certainly a common skill.

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial migration readiness

2010-07-03 Thread Martin v. Löwis 
> This is perhaps a naive question, but hat do you gain with the
> intermediate mirror clone of upstream? (Other than filling more of your
> disk?)

In addition to the answer you got: this way of working is also the
process that I arrived at, independently.

I see two uses, both based around the problem "creating a full clone
will take a long time - much longer than a subversion checkout".
1. if I want several local checkouts (e.g. for testing separate
   features), I can clone them all from the local copy (thereby
   also preserving space, compared to independent clones)
2, throwing away local changes is not that easy in Mercurial,
   if you have committed them already. There are extensions to
   uncommit, but they are discouraged and have limitations. So it's
   best to throw away everything and start over fresh, which is
   faster if you have a pristine clone.

In either case, you keep pulling into the pristine clone from
python.org, and then uppdate your local clones as you please.

When pushing changes, it is best to directly push into the network
(rather than going through the pristine clone): if pushing fails due
to concurrent updates, you haven't cluttered your pristine copy.

Regards,
Martin

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial migration readiness

2010-07-03 Thread Martin v. Löwis 
> My question is basically the same as Terry Reedy's, but I'm going to
> phrase it a bit differently:
> 
> This is perhaps a naive question, but why do you create a second local
> clone instead of just creating a branch?

IIUC, if you create a named branch, the branch will become globally
visible when you push your changes back. I assume people will consider
that clutter - it would be sufficient to just push the changes on the
branch, along with commit messages, but not the branch itself (which
would be only temporary, anyway).

I'm not even sure how you pull changes from one branch into another:
can somebody kindly explain the commands that would be required?

Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial migration readiness

2010-07-03 Thread Martin v. Löwis 
Am 04.07.2010 00:56, schrieb Antoine Pitrou:
> On Sun, 04 Jul 2010 00:51:58 +0200
> "Martin v. Löwis"  wrote:
> I'd love to see a more detailed description of this, including why
> someone new to Mercurial would choose one over the other.
>>>
 I think someone new to Mercurial shouldn't choose either one.
>>>
 Just sit back and wait for the real migration to happen.
>>>
>>> I would say that using the SVN mirror is a fine way to experiment with
>>> using hg against the Python sources to develop and test patches. 
>>
>> I think your description already falls into the "advanced user"
>> category. The new-to-mercurial committer should (IMO) use a "what if it
>> still was svn" workflow, which uses hg pull/up/commit/push.
> 
> This assumes they are accustomed to SVN. I guess not all people are,
> although it is certainly a common skill.

I thought we were talking about Python committers specifically.

Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial migration readiness

2010-07-03 Thread Éric Araujo 
> 2, throwing away local changes is not that easy in Mercurial,
>if you have committed them already. There are extensions to
>uncommit, but they are discouraged and have limitations. So it's
>best to throw away everything and start over fresh, which is
>faster if you have a pristine clone.

If you’re using named branches or bookmarks, there is an easy way to
throw away the whole branch. Say you have a clone with branches default,
fix, fix9008, shlex-unicode (default is clean upstream Python 3.2,
the other three are branches you made for bug fixes or features). Now
you want to discard shlex-unicode.

 $ cd ..
 $ mv cpython cpython.old
 $ hg clone cpython.old cpython -r default -r fix -r fix9008
 $ rm -r cpython.old

The new repo will only contain the branches you ask for. Giving all
names on the command line may be cumbersome if you’re on a lot of
branches at one, but it’s okay for a small number. A small bit of shell
scripting can automate that easily (get all branches, remove the one
given as argument to the shell function, mv, hg clone, rm).

Of course, a branch you wan to abandon can stay in your repo for a while
if you don’t want to clean up now.

HTH. Regards


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Are you ready for Mercurial migration?

2010-07-03 Thread Éric Araujo 
>> That tutorial is not ~100 pages. It's actually a good tutorial.
> That's why I posted it here, but it still >80 pages in my browser.

Perhaps you meant 80 screens, or a different tutorial. hginit is a short
tutorial useful for Subversion users who don’t have the time to read the
hgbook.

Regards


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] blocking 2.7

2010-07-03 Thread anatoly techtonik 
On Sat, Jul 3, 2010 at 3:26 PM, Victor Stinner
 wrote:
>
> In the worst case, a function rejects valid data. If I have to choose, I
> prefer to reject valid data than a security vulnerability. But audioop has
> tests and I don't think that my patch breaks anything :-)

But Python tests lack coverage stats, so it is hard to say anything.
Even with tests it is not always possible to be even 80% sure if
behavior is complicated or depends on the input data.
-- 
anatoly t.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] blocking 2.7

2010-07-03 Thread Éric Araujo 
> But Python tests lack coverage stats, so it is hard to say anything.
FYI: http://coverage.livinglogic.de/

Regards


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com