Re: [Python-Dev] Mercurial sluggishness (was: this is what happens if you freeze all the modules required for startup)

On 15/04/2014 18:32, Daniel Holth wrote: On Tue, Apr 15, 2014 at 1:29 PM, Antoine Pitrou wrote: Le 15/04/2014 19:09, Daniel Holth a écrit : In case you were wondering, I'm using Ubuntu's "2.7.5+" and "3.3.2+". My feeling has long been that the speed of getting at the "--help" option or any i

Re: [Python-Dev] Mercurial sluggishness (was: this is what happens if you freeze all the modules required for startup)

On Tue, Apr 15, 2014 at 1:29 PM, Antoine Pitrou wrote: > Le 15/04/2014 19:09, Daniel Holth a écrit : > >> In case you were wondering, I'm using Ubuntu's "2.7.5+" and "3.3.2+". >> >> My feeling has long been that the speed of getting at the "--help" >> option or any initial user feedback from Mercu

Re: [Python-Dev] Mercurial sluggishness (was: this is what happens if you freeze all the modules required for startup)

On 15 April 2014 18:09, Daniel Holth wrote: > For me Python's startup time (warm) takes about 1/4 of the hg startup > time in the worst case. I expect to both notice and appreciate any > speedups and encourage all optimizers to optimize. My experience is essentially irrelevant (as a Windows user,

Re: [Python-Dev] Mercurial sluggishness (was: this is what happens if you freeze all the modules required for startup)

Le 15/04/2014 19:09, Daniel Holth a écrit : In case you were wondering, I'm using Ubuntu's "2.7.5+" and "3.3.2+". My feeling has long been that the speed of getting at the "--help" option or any initial user feedback from Mercurial or git is a big driver in perceived speed as opposed to how long

Re: [Python-Dev] Mercurial sluggishness (was: this is what happens if you freeze all the modules required for startup)

In case you were wondering, I'm using Ubuntu's "2.7.5+" and "3.3.2+". My feeling has long been that the speed of getting at the "--help" option or any initial user feedback from Mercurial or git is a big driver in perceived speed as opposed to how long the entire operation might take. But for me a

Re: [Python-Dev] Mercurial sluggishness (was: this is what happens if you freeze all the modules required for startup)

Skip Montanaro writes: > "Instant" for me is "the blink of an eye," which Wikipedia reports as > typically between 100ms and 400ms. > If you blink, you've missed > Python 2.7 startup on a relatively modern machine. This is what I see for Mac OS X "Maverick

Re: [Python-Dev] Mercurial sluggishness (was: this is what happens if you freeze all the modules required for startup)

Le 15/04/2014 17:34, Skip Montanaro a écrit : This suggests to me that Mercurial's import slowness is mostly in its own code (I counted 104 Python modules and six shared objects in its mercurial package, which isn't going to be affected (much?) by freezing the Python standard modules. Skip is r

Re: [Python-Dev] Mercurial sluggishness (was: this is what happens if you freeze all the modules required for startup)

Le 15/04/2014 17:42, Daniel Holth a écrit : I find Python's startup time to be very sluggish. I wish it was less than 50 milliseconds (0.05 seconds) including running hg, which is the common threshold for "instant". On my machine 'python -c ""' takes about 0.05 seconds but 'python3 -c ""' takes 0

Re: [Python-Dev] Mercurial sluggishness (was: this is what happens if you freeze all the modules required for startup)

On Wed, Apr 16, 2014 at 1:56 AM, Skip Montanaro wrote: > On Tue, Apr 15, 2014 at 10:42 AM, Daniel Holth wrote: >> I wish it was less >> than 50 milliseconds (0.05 seconds) including running hg, which is the >> common threshold for "instant". > > "Instant" for me is "the blink of an eye," which Wi

Re: [Python-Dev] Mercurial sluggishness (was: this is what happens if you freeze all the modules required for startup)

On Tue, Apr 15, 2014 at 10:42 AM, Daniel Holth wrote: > I wish it was less > than 50 milliseconds (0.05 seconds) including running hg, which is the > common threshold for "instant". "Instant" for me is "the blink of an eye," which Wikipedia reports as typically between 100ms and 400ms.

Re: [Python-Dev] Mercurial sluggishness (was: this is what happens if you freeze all the modules required for startup)

On Tue, Apr 15, 2014 at 10:40 AM, Chris Angelico wrote: > I've no idea whether that's the case or not. All I know is, every time > I need to work with a Mercurial repo it feels a lot slower than doing > similar work on a similar size git repo [1], so any improvement (or > reduction of penalty) wil

Re: [Python-Dev] Mercurial sluggishness (was: this is what happens if you freeze all the modules required for startup)

I find Python's startup time to be very sluggish. I wish it was less than 50 milliseconds (0.05 seconds) including running hg, which is the common threshold for "instant". On my machine 'python -c ""' takes about 0.05 seconds but 'python3 -c ""' takes 0.125 seconds. I will be very happy to see any

[Python-Dev] Mercurial sluggishness (was: this is what happens if you freeze all the modules required for startup)

Eric wrote: > Perhaps not so much "a very real advantage" as "less of a > distraction". It's still significantly slower than 2.7. :) I'm still confused. I peeked in /usr/bin/hg. The only "system" modules it imports directly are os and system (maybe I'm using an ancient version?). After that, it

Re: [Python-Dev] Mercurial sluggishness (was: this is what happens if you freeze all the modules required for startup)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/15/2014 11:34 AM, Skip Montanaro wrote: > I find it hard to believe that freezing the stdlib is going to lower > the barrier enough for the Mercurial folks, if, in fact, import > slowness is their main reason for not moving to 3.x. My understand

Re: [Python-Dev] Mercurial sluggishness (was: this is what happens if you freeze all the modules required for startup)

On Wed, Apr 16, 2014 at 1:34 AM, Skip Montanaro wrote: > I find it hard to believe > that freezing the stdlib is going to lower the barrier enough for the > Mercurial folks, if, in fact, import slowness is their main reason for > not moving to 3.x. I've no idea whether that's the case or not. All

Re: [Python-Dev] Mercurial workflow question...

Raymond Hettinger writes: > Does hg's ability to "make merges easier than svn" depend on having > all the intermediate commits? I thought the theory was that the smaller > changesets provided extra information that made it possible to merge > two expansive groups of changes. Tim Delaney's ex

Re: [Python-Dev] Mercurial workflow question...

Apologies the top-posting (damned Gmail ...). Tim Delaney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Mercurial workflow question...

Possibly. A collapsed changeset is more likely to have larger hunks of changes e.g. two changesets that each modified adjacent pieces of code get collapsed down to a single change hunk - which would make the merge machinery have to work harder to detect moved hunks, etc. In practice, so long as ea

Re: [Python-Dev] Mercurial workflow question...

On Dec 13, 2012, at 7:00 PM, Chris Jerdonek wrote: > On Thu, Dec 13, 2012 at 6:48 PM, R. David Murray > wrote: >> On Thu, 13 Dec 2012 20:21:24 -0500, Trent Nelson wrote: >>>- Use a completely separate clone to house all the intermediate >>> commits, then generate a diff once

Re: [Python-Dev] Mercurial workflow question...

Le Thu, 13 Dec 2012 21:48:23 -0500, "R. David Murray" a écrit : > On Thu, 13 Dec 2012 20:21:24 -0500, Trent Nelson > wrote: > > - Use a completely separate clone to house all the > > intermediate commits, then generate a diff once the final commit is > > ready, then apply that diff to the

Re: [Python-Dev] Mercurial workflow question...

R. David Murray writes: > those commits...if you don't want those intermediate commits in the > official repo, then why is a diff/patch a bad way to achieve that? Because a decent VCS provides TOOWTDI. And sometimes there are different degrees of "intermediate", or pehaps you even want to slic

Re: [Python-Dev] Mercurial workflow question...

In article <20121214024824.3bccc250...@webabinitio.net>, "R. David Murray" wrote: > On Thu, 13 Dec 2012 20:21:24 -0500, Trent Nelson wrote: > > - Use a completely separate clone to house all the intermediate > > commits, then generate a diff once the final commit is ready, > >

Re: [Python-Dev] Mercurial workflow question...

On Dec 14, 2012, at 12:36 PM, Nick Coghlan wrote: >Both Git and Hg recognise there is a difference between interim commits and >ones you want to publish and provide tools to revise a series of commits >into a simpler set for publication to an official repo. One of the things I love about Bazaar i

Re: [Python-Dev] Mercurial workflow question...

On Thu, Dec 13, 2012 at 6:48 PM, R. David Murray wrote: > On Thu, 13 Dec 2012 20:21:24 -0500, Trent Nelson wrote: >> - Use a completely separate clone to house all the intermediate >> commits, then generate a diff once the final commit is ready, >> then apply that diff

Re: [Python-Dev] Mercurial workflow question...

On Thu, 13 Dec 2012 20:21:24 -0500, Trent Nelson wrote: > - Use a completely separate clone to house all the intermediate > commits, then generate a diff once the final commit is ready, > then apply that diff to the main cpython repo, then push that. > This ap

Re: [Python-Dev] Mercurial workflow question...

On Fri, Dec 14, 2012 at 12:02 PM, Larry Hastings wrote: > On 12/13/2012 05:21 PM, Trent Nelson wrote: > > Thoughts? > > > % hg help rebase > And also the histedit extension (analagous to "git rebase -i"). Both Git and Hg recognise there is a difference between interim commits and ones you

Re: [Python-Dev] Mercurial workflow question...

On 12/13/2012 05:21 PM, Trent Nelson wrote: Thoughts? % hg help rebase //arry/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/

[Python-Dev] Mercurial workflow question...

Scenario: I'm working on a change that I want to actively test on a bunch of Snakebite hosts. Getting the change working is going to be an iterative process -- lots of small commits trying to attack the problem one little bit at a time. Eventually I'll get to a point where I'm

[Python-Dev] Mercurial workflow: merging from 3.2

Hey all, I realise that we're still getting used to the workflows, but there are currently unmerged changesets (in test_peepholer and friends) on the 3.2 branch that seem to have been applied *separately* to 3.3. This causes problems for anyone else who wants to merge changes from 3.2 to 3.3 a

Re: [Python-Dev] Mercurial conversion repositories

Le vendredi 04 mars 2011 à 14:03 -0800, Santoso Wijaya a écrit : > [...] publishing patches by referring to a remote repository, > rather than uploading the diff. > > > Is this a recommended workflow at this point, or should we > generate/attach patch files still? Both, for experi

Re: [Python-Dev] Mercurial conversion repositories

> > [...] publishing patches by referring to a remote repository, > rather than uploading the diff. > Is this a recommended workflow at this point, or should we generate/attach patch files still? Both, for experimentation? ~/santa On Fri, Mar 4, 2011 at 1:15 PM, "Martin v. Löwis" wrote: > > As

Re: [Python-Dev] Mercurial conversion repositories

> As a mercurial user, I thank you for this effort! One question, > where/how do I send suggestion to what to add into .hgignore file? In > particular, I found these dynamically generated files after a build in > Windows (3.2) that probably should be entered as .hgignore entries: All patches shoul

Re: [Python-Dev] Mercurial conversion repositories

Hi, As a mercurial user, I thank you for this effort! One question, where/how do I send suggestion to what to add into .hgignore file? In particular, I found these dynamically generated files after a build in Windows (3.2) that probably should be entered as .hgignore entries: ? PC/python_nt_d.h ?

Re: [Python-Dev] Mercurial conversion repositories

On Mon, 28 Feb 2011 16:07:48 -0500 Barry Warsaw wrote: > On Feb 28, 2011, at 04:15 PM, Antoine Pitrou wrote: > > >On Mon, 28 Feb 2011 10:08:26 -0500 > >Barry Warsaw wrote: > >> > >> >BTW, I had not heard of hgeditor before, and wrote a small hg extension to > >> >do what you want (with HG: pref

Re: [Python-Dev] Mercurial conversion repositories

On Feb 28, 2011, at 04:15 PM, Antoine Pitrou wrote: >On Mon, 28 Feb 2011 10:08:26 -0500 >Barry Warsaw wrote: >> >> >BTW, I had not heard of hgeditor before, and wrote a small hg extension to >> >do what you want (with HG: prefix :) before I saw that others had already >> >replied with hgeditor.

Re: [Python-Dev] Mercurial conversion repositories

On Mon, 28 Feb 2011 10:08:26 -0500 Barry Warsaw wrote: > > >BTW, I had not heard of hgeditor before, and wrote a small hg extension to > >do what you want (with HG: prefix :) before I saw that others had already > >replied with hgeditor. The extension had 10 lines of code. > > We should find a

Re: [Python-Dev] Mercurial conversion repositories

On Feb 27, 2011, at 05:38 PM, Georg Brandl wrote: >While I understand the usefulness of the diff feature, it is not useful to >everyone, e.g. those using almost exclusively ``commit -m message``. The editor window doesn't pop up when you provide the -m flag, so the diff output is not relevant. >

Re: [Python-Dev] Mercurial conversion repositories

Barry Warsaw writes: > You mean, TortoiseHg supports incremental commits on a single file? That's > kind of neat, but scary. ;) Darcs people have been doing this for, well, for as long as Darcs has existed. It's not scary at all. In fact, in Darcs you can select hunks across files, too. __

Re: [Python-Dev] Mercurial conversion repositories

On 26.02.2011 21:49, Barry Warsaw wrote: > On Feb 26, 2011, at 01:49 AM, Éric Araujo wrote: > >>You speak to my heart, sir. In your ~/.hgrc, under the section [ui], >>set “editor = path/to/mercurial/source/hgeditor” and enjoy your diffs. >>I use it and love it. > > Except it doesn't quite work t

Re: [Python-Dev] Mercurial conversion repositories

On Sun, 27 Feb 2011 08:09:21 +0100 "Martin v. Löwis" wrote: > >> changeset: 72694:e65daae6cf44 > >> user:Antoine Pitrou > >> date:Mon Feb 21 21:30:55 2011 + > >> summary: Try s/UINT_MAX/INT_MAX/ > > > > It's not on an unnamed branch, it's on the "default" branch (which

Re: [Python-Dev] Mercurial conversion repositories

>> changeset: 72694:e65daae6cf44 >> user:Antoine Pitrou >> date:Mon Feb 21 21:30:55 2011 + >> summary: Try s/UINT_MAX/INT_MAX/ > > It's not on an unnamed branch, it's on the "default" branch (which is > omitted for concision by "hg log" and other commands with a similar

Re: [Python-Dev] Mercurial conversion repositories

On 2011-02-27 01:50, Barry Warsaw wrote: > On Feb 26, 2011, at 11:45 PM, Adrian Buehlmann wrote: > >> You'd have to take this up with Mercurial's BDFL Matt. He is a strong >> advocate for teaching users to learn edit their .hg/hgrc files. > > Well, I guess it's doubtful I'd change his mind then.

Re: [Python-Dev] Mercurial conversion repositories

On Feb 26, 2011, at 11:45 PM, Adrian Buehlmann wrote: >You'd have to take this up with Mercurial's BDFL Matt. He is a strong >advocate for teaching users to learn edit their .hg/hgrc files. Well, I guess it's doubtful I'd change his mind then. :) >Regarding Bazaar: FWIW, I periodically retried t

Re: [Python-Dev] Mercurial conversion repositories

On Sat, Feb 26, 2011 at 1:37 PM, Brett Cannon wrote: > There is hg-git, but that is hg on top of git. > Actually, hg-git is bidirectional. The hg-git documentation is written from the perspective of an hg client talking to a git server, but for a DVCS "client" and "server" are a matter of pers

Re: [Python-Dev] Mercurial conversion repositories

On 2011-02-26 22:06, Barry Warsaw wrote: > On Feb 26, 2011, at 02:05 PM, R. David Murray wrote: > >> On Sat, 26 Feb 2011 13:08:47 -0500, Barry Warsaw wrote: >>> $ cd py27 # now I want to synchronize >>> $ hg pull -u ssh://h...@hg.python.org/cpython >>> >>> but I'm not going to remember that url e

Re: [Python-Dev] Mercurial conversion repositories

On Sat, Feb 26, 2011 at 3:09 PM, Brett Cannon wrote: > Hg's is the mq (Mercurial Queue) extension. I prefer the hg shelve plugin (http://mercurial.selenic.com/wiki/ShelveExtension) for this, more intuitive to me ___ Python-Dev mailing list Python-Dev@py

Re: [Python-Dev] Mercurial conversion repositories

On Sat, Feb 26, 2011 at 13:30, Barry Warsaw wrote: > On Feb 26, 2011, at 12:09 PM, Brett Cannon wrote: > > >For other people's benefit, LoD == line of development (I think). > > Yes. It's just a word that isn't intimately tied to the implementation > details of a specific dVCS. > > >> I clone th

Re: [Python-Dev] Mercurial conversion repositories

On Feb 26, 2011, at 10:20 PM, Antoine Pitrou wrote: >Often (but not always), when you're wanting to do something, there's an >extension for Mercurial which can be enabled ;) >http://mercurial.selenic.com/wiki/ShareExtension You sound like an iPhone commercial: "There's an app for that." :) -Bar

Re: [Python-Dev] Mercurial conversion repositories

On Feb 26, 2011, at 12:09 PM, Brett Cannon wrote: >For other people's benefit, LoD == line of development (I think). Yes. It's just a word that isn't intimately tied to the implementation details of a specific dVCS. >> I clone the remote repository using the command in the devguide, so I now >>

Re: [Python-Dev] Mercurial conversion repositories

On Sat, 26 Feb 2011 16:06:45 -0500 Barry Warsaw wrote: > > >I find bazaar's model confusing, and hg's intuitive, just like Éric. > >And consider that I learned bazaar before mercurial. To me, it makes > >perfect sense that in a DVCS the "unit" is a directory containing > >a repository and a wor

Re: [Python-Dev] Mercurial conversion repositories

On Feb 26, 2011, at 02:05 PM, R. David Murray wrote: >On Sat, 26 Feb 2011 13:08:47 -0500, Barry Warsaw wrote: >> $ cd py27 # now I want to synchronize >> $ hg pull -u ssh://h...@hg.python.org/cpython >> >> but I'm not going to remember that url every time. It wouldn't be so bad if >> Mercurial

Re: [Python-Dev] Mercurial conversion repositories

On 27 February 2011 01:40, Nick Coghlan wrote: > On Sat, Feb 26, 2011 at 4:34 PM, Georg Brandl wrote: > >> Would it be possible to name "trunk" as "2.x" instead? Otherwise I > >> could see people getting confused and asking why trunk was closed, > >> and/or not the same as "default". > > > > Pro

Re: [Python-Dev] Mercurial conversion repositories

On Feb 26, 2011, at 01:49 AM, Éric Araujo wrote: >You speak to my heart, sir. In your ~/.hgrc, under the section [ui], >set “editor = path/to/mercurial/source/hgeditor” and enjoy your diffs. >I use it and love it. Except it doesn't quite work the way I want it to (hg 1.6.3). It opens your edito

Re: [Python-Dev] Mercurial conversion repositories

On Sat, Feb 26, 2011 at 10:08, Barry Warsaw wrote: > On Feb 26, 2011, at 01:49 AM, Éric Araujo wrote: > > >Le 25/02/2011 20:43, Barry Warsaw a écrit : > >> On Feb 25, 2011, at 06:40 PM, Adrian Buehlmann wrote: > >> [snip] > >>> Note that each of these branch clones will initially have your local

Re: [Python-Dev] Mercurial conversion repositories

On Fri, Feb 25, 2011 at 13:46, Barry Warsaw wrote: > On Feb 25, 2011, at 09:04 PM, Philippe Fremy wrote: > > >What you are asking for is available in TortoiseHg which absolutely > >rocks (if you are not allergic to the idea of a graphical tool). > > Like shellfish, bee-strings, and Perl I'm afrai

Re: [Python-Dev] Mercurial conversion repositories

On Sat, 26 Feb 2011 13:08:47 -0500, Barry Warsaw wrote: > $ cd py27 # now I want to synchronize > $ hg pull -u ssh://h...@hg.python.org/cpython > > but I'm not going to remember that url every time. It wouldn't be so bad if > Mercurial remembered the pull URL for me, as (you guessed it :) Bazaar

Re: [Python-Dev] Mercurial conversion repositories

>From http://mercurial.selenic.com/wiki/Branch#Named_branches: [...] a good rule of thumb is to use branch names sparingly and for rather longer lived concepts like "release branches" (rel-1, rel-2, etc) and rather not for short lived work of single developers So I think named branches make sense

Re: [Python-Dev] Mercurial conversion repositories

A Mercurial 'merge' is simply a creation of another changeset, which has two parents: the current tip of the branch you're working on, and the changeset you are merging with. ~/santa On Sat, Feb 26, 2011 at 10:23 AM, Barry Warsaw wrote: > On Feb 26, 2

Re: [Python-Dev] Mercurial conversion repositories

On Sat, Feb 26, 2011 at 9:55 AM, Antoine Pitrou wrote: > There is no such thing as an "unnamed branch". What would "hg branches" > show? An empty space? > I understand now why I was confused. I had previously read the sentence "Both Git and Mercurial support unnamed local branches." at http://m

Re: [Python-Dev] Mercurial conversion repositories

> >> But is there a need to have any changesets in the "trunk" named branch? > >> Couldn't the historical changesets just be in an unnamed branch, being > >> ancestor of so many named branches? > > > > There is no such thing as an "unnamed branch". What would "hg branches" > > show? An empty spac

Re: [Python-Dev] Mercurial conversion repositories

On Feb 26, 2011, at 06:32 PM, Éric Araujo wrote: >>> Named branches are exclusive, they can't be a subset of each other ;) > >Actually, they can. Take the example of the Mercurial repo itself. They >fix bugs in the stable branch and add features in default. When they >merge stable into default a

Re: [Python-Dev] Mercurial conversion repositories

>> But is there a need to have any changesets in the "trunk" named branch? >> Couldn't the historical changesets just be in an unnamed branch, being >> ancestor of so many named branches? > > There is no such thing as an "unnamed branch". What would "hg branches" > show? An empty space? hg branch

Re: [Python-Dev] Mercurial conversion repositories

On Feb 26, 2011, at 01:49 AM, Éric Araujo wrote: >Le 25/02/2011 20:43, Barry Warsaw a écrit : >> On Feb 25, 2011, at 06:40 PM, Adrian Buehlmann wrote: >> [snip] >>> Note that each of these branch clones will initially have your local >>> master repo as the default path [3,4]. If you'd like to have

Re: [Python-Dev] Mercurial conversion repositories

Le samedi 26 février 2011 à 18:36 +0100, "Martin v. Löwis" a écrit : > Am 26.02.2011 17:44, schrieb Antoine Pitrou: > > Le samedi 26 février 2011 à 08:38 -0800, Daniel Stutzbach a écrit : > >> On Fri, Feb 25, 2011 at 6:32 PM, Nick Coghlan > >> wrote: > >> Would it be possible to name "trun

Re: [Python-Dev] Mercurial conversion repositories

Am 26.02.2011 17:44, schrieb Antoine Pitrou: > Le samedi 26 février 2011 à 08:38 -0800, Daniel Stutzbach a écrit : >> On Fri, Feb 25, 2011 at 6:32 PM, Nick Coghlan >> wrote: >> Would it be possible to name "trunk" as "2.x" instead? >> Otherwise I >> could see people getting

Re: [Python-Dev] Mercurial conversion repositories

Le samedi 26 février 2011 à 09:27 -0800, Daniel Stutzbach a écrit : > On Sat, Feb 26, 2011 at 8:44 AM, Antoine Pitrou > wrote: > Le samedi 26 février 2011 à 08:38 -0800, Daniel Stutzbach a > écrit : > > > Can we just get rid of "trunk" altogether? It's history is

Re: [Python-Dev] Mercurial conversion repositories

>> Named branches are exclusive, they can't be a subset of each other ;) Actually, they can. Take the example of the Mercurial repo itself. They fix bugs in the stable branch and add features in default. When they merge stable into default and commit, default becomes a superset of stable. That

Re: [Python-Dev] Mercurial conversion repositories

On Sat, Feb 26, 2011 at 8:44 AM, Antoine Pitrou wrote: > Le samedi 26 février 2011 à 08:38 -0800, Daniel Stutzbach a écrit : > > Can we just get rid of "trunk" altogether? It's history is a strict > > subset of the 2.7 branch's history, isn't it? > > Named branches are exclusive, they can't be a

Re: [Python-Dev] Mercurial conversion repositories

>> Can we just use default for trunk and py3k? For the time when both >> trunk and py3k were active, it would create two unnamed branches on the >> default branch, but one merge would solve that. > > IMO, a dummy merge at the tip of the default branch may confuse users > looking at the history, e

Re: [Python-Dev] Mercurial conversion repositories

On Sun, Feb 27, 2011 at 3:00 AM, Antoine Pitrou wrote: > Besides, it would precisely make it harder to distinguish between > trunk and py3k development at the time both took place in parallel. With the legacy branches now being closed so they don't appear in the default output from hg commands, I

Re: [Python-Dev] Mercurial conversion repositories

On Sat, 26 Feb 2011 17:49:32 +0100 Éric Araujo wrote: > Le 26/02/2011 17:44, Antoine Pitrou a écrit : > >> Can we just get rid of "trunk" altogether? It's history is a strict > >> subset of the 2.7 branch's history, isn't it? > > > > Named branches are exclusive, they can't be a subset of each o

Re: [Python-Dev] Mercurial conversion repositories

Le 26/02/2011 17:44, Antoine Pitrou a écrit : >> Can we just get rid of "trunk" altogether? It's history is a strict >> subset of the 2.7 branch's history, isn't it? > > Named branches are exclusive, they can't be a subset of each other ;) Can we just use default for trunk and py3k? For the tim

Re: [Python-Dev] Mercurial conversion repositories

Le samedi 26 février 2011 à 08:38 -0800, Daniel Stutzbach a écrit : > On Fri, Feb 25, 2011 at 6:32 PM, Nick Coghlan > wrote: > Would it be possible to name "trunk" as "2.x" instead? > Otherwise I > could see people getting confused and asking why trunk was > closed,

Re: [Python-Dev] Mercurial conversion repositories

On Fri, Feb 25, 2011 at 6:32 PM, Nick Coghlan wrote: > Would it be possible to name "trunk" as "2.x" instead? Otherwise I > could see people getting confused and asking why trunk was closed, > and/or not the same as "default". > Can we just get rid of "trunk" altogether? It's history is a stric

Re: [Python-Dev] Mercurial conversion repositories

> Although I now admit "legacy-trunk" sounds quite accurate, and conveys > a clear warning to anyone wondering if they should use it. To stay in tree terminology, I propose "stump" (*). Or "rotten-trunk". Bikeshedding is such a fun activity :-) Regards, Martin (*) m-w.com: "the part of a plant

Re: [Python-Dev] Mercurial conversion repositories

Am 26.02.2011 15:42, schrieb Nick Coghlan: > On Sat, Feb 26, 2011 at 7:29 PM, "Martin v. Löwis" wrote: >>> I think people should simply get used to the idea that "default" is >>> /the/ main branch in Mercurial (*). It's even easier to remember IMHO >>> ("trunk" sounds a bit obscure at first, for a

Re: [Python-Dev] Mercurial conversion repositories

On Sat, 26 Feb 2011 15:44:08 +0100 Antoine Pitrou wrote: > Le dimanche 27 février 2011 à 00:42 +1000, Nick Coghlan a écrit : > > On Sat, Feb 26, 2011 at 7:29 PM, "Martin v. Löwis" > > wrote: > > >> I think people should simply get used to the idea that "default" is > > >> /the/ main branch in Me

Re: [Python-Dev] Mercurial conversion repositories

On 26/02/2011 14:44, Antoine Pitrou wrote: Le dimanche 27 février 2011 à 00:42 +1000, Nick Coghlan a écrit : On Sat, Feb 26, 2011 at 7:29 PM, "Martin v. Löwis" wrote: I think people should simply get used to the idea that "default" is /the/ main branch in Mercurial (*). It's even easier to rem

Re: [Python-Dev] Mercurial conversion repositories

Le dimanche 27 février 2011 à 00:42 +1000, Nick Coghlan a écrit : > On Sat, Feb 26, 2011 at 7:29 PM, "Martin v. Löwis" wrote: > >> I think people should simply get used to the idea that "default" is > >> /the/ main branch in Mercurial (*). It's even easier to remember IMHO > >> ("trunk" sounds a b

Re: [Python-Dev] Mercurial conversion repositories

On Sat, Feb 26, 2011 at 7:29 PM, "Martin v. Löwis" wrote: >> I think people should simply get used to the idea that "default" is >> /the/ main branch in Mercurial (*). It's even easier to remember IMHO >> ("trunk" sounds a bit obscure at first, for a non-native English >> speaker). > > +1. People

Re: [Python-Dev] Mercurial conversion repositories

On Sat, Feb 26, 2011 at 4:34 PM, Georg Brandl wrote: >> Would it be possible to name "trunk" as "2.x" instead? Otherwise I >> could see people getting confused and asking why trunk was closed, >> and/or not the same as "default". > > Problem is, you then have 1.5.2 released from the 2.x branch :)

Re: [Python-Dev] Mercurial conversion repositories

Antoine Pitrou wrote: On Sat, 26 Feb 2011 12:32:04 +1000 Nick Coghlan wrote: On Fri, Feb 25, 2011 at 10:19 AM, Antoine Pitrou wrote: $ hg branches default68026:f12ef116dd10 3.268025:cef92ee1a323 2.768010:8174d00d0

Re: [Python-Dev] Mercurial conversion repositories

> I think people should simply get used to the idea that "default" is > /the/ main branch in Mercurial (*). It's even easier to remember IMHO > ("trunk" sounds a bit obscure at first, for a non-native English > speaker). +1. People will recognize "trunk" as a svn think. If that doesn't clue them i

Re: [Python-Dev] Mercurial conversion repositories

On 26.02.2011 03:32, Nick Coghlan wrote: > On Fri, Feb 25, 2011 at 10:19 AM, Antoine Pitrou wrote: >>$ hg branches >>default68026:f12ef116dd10 >>3.268025:cef92ee1a323 >>2.768010:8174d00d0797 >>3.1

Re: [Python-Dev] Mercurial conversion repositories

On Sat, 26 Feb 2011 12:32:04 +1000 Nick Coghlan wrote: > On Fri, Feb 25, 2011 at 10:19 AM, Antoine Pitrou wrote: > >    $ hg branches > >    default                    68026:f12ef116dd10 > >    3.2                        68025:cef92ee1a323 > >    2.7                        68010:8174d00d0797 > >

Re: [Python-Dev] Mercurial conversion repositories

On Fri, Feb 25, 2011 at 10:19 AM, Antoine Pitrou wrote: >    $ hg branches >    default                    68026:f12ef116dd10 >    3.2                        68025:cef92ee1a323 >    2.7                        68010:8174d00d0797 >    3.1                        67955:5be8b695ea86 >    2.6          

Re: [Python-Dev] Mercurial conversion repositories

Hi, Le 25/02/2011 20:43, Barry Warsaw a écrit : > On Feb 25, 2011, at 06:40 PM, Adrian Buehlmann wrote: > [snip] >> Note that each of these branch clones will initially have your local >> master repo as the default path [3,4]. If you'd like to have the default >> push/pull path to point to ssh://h

Re: [Python-Dev] Mercurial conversion repositories

On 25Feb2011 14:43, Barry Warsaw wrote: | [...] And I have to | remember to fiddle with .hg/hgrc when I clone a new branch working directory, | but I guess that's mostly a one-time cost. Hmm. Why do you need to fiddle with the hgrc? Just curious. | I'll have to remember that 'hg pull' does not

Re: [Python-Dev] Mercurial conversion repositories

On Feb 25, 2011, at 09:04 PM, Philippe Fremy wrote: >What you are asking for is available in TortoiseHg which absolutely >rocks (if you are not allergic to the idea of a graphical tool). Like shellfish, bee-strings, and Perl I'm afraid. :) >You can even select indvidually inside a file which lin

Re: [Python-Dev] Mercurial conversion repositories

Le samedi 26 février 2011 à 08:40 +1100, Neil Hodgson a écrit : > Antoine Pitrou: > > > It should now be fixed in current SVN, meaning the final conversion > > should be perfectly usable with the eol extension enabled. > >Good. > > > Do you find other issues under Windows? Have you tried pus

Re: [Python-Dev] Mercurial conversion repositories

Antoine Pitrou: > It should now be fixed in current SVN, meaning the final conversion > should be perfectly usable with the eol extension enabled. Good. > Do you find other issues under Windows? Have you tried pushing changes? Since I'm not a member of core developers I used a http pull a

Re: [Python-Dev] Mercurial conversion repositories

On 25/02/2011 20:43, Barry Warsaw wrote: > > One immediate thing that I'm missing from Bazaar is that 'bzr commit' invokes > my editor and always shows me a 'diff -u' in the commit message buffer. This > is incredibly handy because I don't have to remember to do the diff in a > different window, a

Re: [Python-Dev] Mercurial conversion repositories

On Fri, 25 Feb 2011 14:43:15 -0500 Barry Warsaw wrote: > > I'll have to remember that 'hg pull' does not update the working copy by > default, and eventually I'll figure out the whole merge thing. You can use "hg pull -u" to update (and "hg pull -uv" if you want to see the list of updated files)

Re: [Python-Dev] Mercurial conversion repositories

On Feb 25, 2011, at 06:40 PM, Adrian Buehlmann wrote: >First, get an initial clone (let's name it 'master') over the wire >using: [1] > > $ hg clone -U ssh://h...@hg.python.org/cpython master > >Then create a hardlinked clone [2] for working in each branch, >specifying the branch to check out usi

Re: [Python-Dev] Mercurial conversion repositories

On 2011-02-25 17:12, Barry Warsaw wrote: > On Feb 25, 2011, at 01:50 AM, Raymond Hettinger wrote: > >> >> On Feb 25, 2011, at 12:09 AM, Martin v. Löwis wrote: >> >>> I think I would have liked the strategy of the PEP better (i.e. >>> create clones for feature branches, rather than putting all >>>

Re: [Python-Dev] Mercurial conversion repositories

On Fri, 25 Feb 2011 13:52:58 +0100 Antoine Pitrou wrote: > On Fri, 25 Feb 2011 19:13:49 +1100 > Neil Hodgson wrote: > >With hg 1.7.5 on Windows 7 I performed a non-core checkout: > > > > hg clone http://hg.python.org/cpython > > > >The eol extension is enabled in global settings. > > Y

Re: [Python-Dev] Mercurial conversion repositories

On 25.02.2011 17:31, Georg Brandl wrote: > On 25.02.2011 17:12, Barry Warsaw wrote: >> On Feb 25, 2011, at 01:50 AM, Raymond Hettinger wrote: >> >>> >>>On Feb 25, 2011, at 12:09 AM, Martin v. Löwis wrote: >>> I think I would have liked the strategy of the PEP better (i.e. create clones f

Re: [Python-Dev] Mercurial conversion repositories

On 25.02.2011 17:12, Barry Warsaw wrote: > On Feb 25, 2011, at 01:50 AM, Raymond Hettinger wrote: > >> >>On Feb 25, 2011, at 12:09 AM, Martin v. Löwis wrote: >> >>> I think I would have liked the strategy of the PEP better (i.e. >>> create clones for feature branches, rather than putting all >>> i

Re: [Python-Dev] Mercurial conversion repositories

Hi Barry, > The way I work with the Subversion branches is to have all the active branches > checked out into separate directories under a common parent, e.g. > > ~/projects/python/py26 > ~/projects/python/py27 > ~/projects/python/trunk > ~/projects/python/py31 > ~/projects/python/py32 > ~/proje

Re: [Python-Dev] Mercurial conversion repositories

On Feb 25, 2011, at 01:50 AM, Raymond Hettinger wrote: > >On Feb 25, 2011, at 12:09 AM, Martin v. Löwis wrote: > >> I think I would have liked the strategy of the PEP better (i.e. >> create clones for feature branches, rather than putting all >> in a single repository). > >In my brief tests, the s

  1   2   3   4   5   6   >