On Wed, Apr 16, 2014 at 1:34 AM, Skip Montanaro s...@pobox.com 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
-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
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
On Tue, Apr 15, 2014 at 10:40 AM, Chris Angelico ros...@gmail.com 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
On Tue, Apr 15, 2014 at 10:42 AM, Daniel Holth dho...@gmail.com 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.
On Wed, Apr 16, 2014 at 1:56 AM, Skip Montanaro s...@pobox.com wrote:
On Tue, Apr 15, 2014 at 10:42 AM, Daniel Holth dho...@gmail.com 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
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
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.125
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
Skip Montanaro writes:
Instant for me is the blink of an eye, which Wikipedia reports as
typically between 100ms and 400ms.
http://en.wikipedia.org/wiki/Blink If you blink, you've missed
Python 2.7 startup on a relatively modern machine.
This is what I see for Mac OS X Mavericks on a
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 any
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 the
On 15 April 2014 18:09, Daniel Holth dho...@gmail.com 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
On Tue, Apr 15, 2014 at 1:29 PM, Antoine Pitrou solip...@pitrou.net 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
On 15/04/2014 18:32, Daniel Holth wrote:
On Tue, Apr 15, 2014 at 1:29 PM, Antoine Pitrou solip...@pitrou.net 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
On Dec 13, 2012, at 7:00 PM, Chris Jerdonek chris.jerdo...@gmail.com wrote:
On Thu, Dec 13, 2012 at 6:48 PM, R. David Murray rdmur...@bitdance.com
wrote:
On Thu, 13 Dec 2012 20:21:24 -0500, Trent Nelson tr...@snakebite.org wrote:
- Use a completely separate clone to house all the
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
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
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
Le Thu, 13 Dec 2012 21:48:23 -0500,
R. David Murray rdmur...@bitdance.com a écrit :
On Thu, 13 Dec 2012 20:21:24 -0500, Trent Nelson
tr...@snakebite.org wrote:
- Use a completely separate clone to house all the
intermediate commits, then generate a diff once the final commit is
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
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:
On Fri, Dec 14, 2012 at 12:02 PM, Larry Hastings la...@hastings.org 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
On Thu, 13 Dec 2012 20:21:24 -0500, Trent Nelson tr...@snakebite.org 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.
On Thu, Dec 13, 2012 at 6:48 PM, R. David Murray rdmur...@bitdance.com wrote:
On Thu, 13 Dec 2012 20:21:24 -0500, Trent Nelson tr...@snakebite.org wrote:
- Use a completely separate clone to house all the intermediate
commits, then generate a diff once the final commit is
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 is
In article 20121214024824.3bccc250...@webabinitio.net,
R. David Murray rdmur...@bitdance.com wrote:
On Thu, 13 Dec 2012 20:21:24 -0500, Trent Nelson tr...@snakebite.org wrote:
- Use a completely separate clone to house all the intermediate
commits, then generate a diff once
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 slice,
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
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
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 should
[...] 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
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
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.
Of
On Mon, 28 Feb 2011 10:08:26 -0500
Barry Warsaw ba...@python.org 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
On Feb 28, 2011, at 04:15 PM, Antoine Pitrou wrote:
On Mon, 28 Feb 2011 10:08:26 -0500
Barry Warsaw ba...@python.org 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
On Mon, 28 Feb 2011 16:07:48 -0500
Barry Warsaw ba...@python.org wrote:
On Feb 28, 2011, at 04:15 PM, Antoine Pitrou wrote:
On Mon, 28 Feb 2011 10:08:26 -0500
Barry Warsaw ba...@python.org wrote:
BTW, I had not heard of hgeditor before, and wrote a small hg extension to
do what you
On Sun, 27 Feb 2011 08:09:21 +0100
Martin v. Löwis mar...@v.loewis.de wrote:
changeset: 72694:e65daae6cf44
user:Antoine Pitrou solip...@pitrou.net
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
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 the way I
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.
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 in, they
Antoine Pitrou wrote:
On Sat, 26 Feb 2011 12:32:04 +1000
Nick Coghlan ncogh...@gmail.com wrote:
On Fri, Feb 25, 2011 at 10:19 AM, Antoine Pitrou solip...@pitrou.net wrote:
$ hg branches
default68026:f12ef116dd10
3.268025:cef92ee1a323
2.7
On Sat, Feb 26, 2011 at 4:34 PM, Georg Brandl g.bra...@gmx.net 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
On Sat, Feb 26, 2011 at 7:29 PM, Martin v. Löwis mar...@v.loewis.de 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.
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 mar...@v.loewis.de 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
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öwismar...@v.loewis.de wrote:
I think people should simply get used to the idea that default is
/the/ main branch in Mercurial (*). It's
On Sat, 26 Feb 2011 15:44:08 +0100
Antoine Pitrou solip...@pitrou.net 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 mar...@v.loewis.de
wrote:
I think people should simply get used to the idea that default is
Am 26.02.2011 15:42, schrieb Nick Coghlan:
On Sat, Feb 26, 2011 at 7:29 PM, Martin v. Löwis mar...@v.loewis.de 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,
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 and
On Fri, Feb 25, 2011 at 6:32 PM, Nick Coghlan ncogh...@gmail.com 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
Le samedi 26 février 2011 à 08:38 -0800, Daniel Stutzbach a écrit :
On Fri, Feb 25, 2011 at 6:32 PM, Nick Coghlan ncogh...@gmail.com
wrote:
Would it be possible to name trunk as 2.x instead?
Otherwise I
could see people getting confused and asking why trunk was
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 time when
On Sat, 26 Feb 2011 17:49:32 +0100
Éric Araujo mer...@netwok.org 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
On Sun, Feb 27, 2011 at 3:00 AM, Antoine Pitrou solip...@pitrou.net 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
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,
On Sat, Feb 26, 2011 at 8:44 AM, Antoine Pitrou solip...@pitrou.net 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
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
Le samedi 26 février 2011 à 09:27 -0800, Daniel Stutzbach a écrit :
On Sat, Feb 26, 2011 at 8:44 AM, Antoine Pitrou solip...@pitrou.net
wrote:
Le samedi 26 février 2011 à 08:38 -0800, Daniel Stutzbach a
écrit :
Can we just get rid of trunk altogether? It's
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 ncogh...@gmail.com
wrote:
Would it be possible to name trunk as 2.x instead?
Otherwise I
could see people
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 ncogh...@gmail.com
wrote:
Would it be possible to name
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 the
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 branches doesn't
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 and
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 branches
On Sat, Feb 26, 2011 at 9:55 AM, Antoine Pitrou solip...@pitrou.net 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.
A Mercurial 'merge' http://mercurial.selenic.com/wiki/Branch 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 ba...@python.org wrote:
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
On Sat, 26 Feb 2011 13:08:47 -0500, Barry Warsaw ba...@python.org 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
On Fri, Feb 25, 2011 at 13:46, Barry Warsaw ba...@python.org 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
On Sat, Feb 26, 2011 at 10:08, Barry Warsaw ba...@python.org 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
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
editor
On 27 February 2011 01:40, Nick Coghlan ncogh...@gmail.com wrote:
On Sat, Feb 26, 2011 at 4:34 PM, Georg Brandl g.bra...@gmx.net 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
On Feb 26, 2011, at 02:05 PM, R. David Murray wrote:
On Sat, 26 Feb 2011 13:08:47 -0500, Barry Warsaw ba...@python.org 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
On Sat, 26 Feb 2011 16:06:45 -0500
Barry Warsaw ba...@python.org 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
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
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.
:)
-Barry
On Sat, Feb 26, 2011 at 13:30, Barry Warsaw ba...@python.org 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
On Sat, Feb 26, 2011 at 3:09 PM, Brett Cannon br...@python.org 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
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 ba...@python.org 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
On Sat, Feb 26, 2011 at 1:37 PM, Brett Cannon br...@python.org 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
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 the
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. :)
changeset: 72694:e65daae6cf44
user:Antoine Pitrou solip...@pitrou.net
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
Georg and I have been working on converting the SVN repository to
Mercurial. We can now present you a test repository (actually, two).
Thanks for working on this!
How do you want bugs reported?
Can you please update the PEP? I see at least the following deviations:
- the extrahist repository
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. I looked at things
a bit, opening some files and using the Tortoise Hg Repository
Explorer. But made no actual changes. Running hg diff
On Fri, Feb 25, 2011 at 09:09, Martin v. Löwis mar...@v.loewis.de 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).
Unnamed heads are trivial to convert to clones.
Cheers,
Dirkjan
Am 25.02.2011 09:17, schrieb Dirkjan Ochtman:
On Fri, Feb 25, 2011 at 09:09, Martin v. Löwis mar...@v.loewis.de 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).
Unnamed heads are
On Fri, Feb 25, 2011 at 09:25, Martin v. Löwis mar...@v.loewis.de wrote:
If there are hundreds of them, it's far from trivial. I don't even know
how to find out which one to convert.
Right, I mostly mean it's trivial for Antoine or Georg to extract into
a clone (at least that's how I was
Am 25.02.2011 09:29, schrieb Dirkjan Ochtman:
On Fri, Feb 25, 2011 at 09:25, Martin v. Löwis mar...@v.loewis.de wrote:
If there are hundreds of them, it's far from trivial. I don't even know
how to find out which one to convert.
Right, I mostly mean it's trivial for Antoine or Georg to
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 single repository has been easy to work with.
If they were
On Fri, 25 Feb 2011 19:13:49 +1100
Neil Hodgson nyamaton...@gmail.com 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.
Yes, please try to disable it. The issue is we have a .hgeol
On Thu, 24 Feb 2011 17:39:40 -0800
Brett Cannon br...@python.org wrote:
Your clone will contain the following branches:
$ hg branches
default68026:f12ef116dd10
3.268025:cef92ee1a323
2.768010:8174d00d0797
On 25.02.2011 09:25, Martin v. Löwis wrote:
Am 25.02.2011 09:17, schrieb Dirkjan Ochtman:
On Fri, Feb 25, 2011 at 09:09, Martin v. Löwis mar...@v.loewis.de 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
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 single
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
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
in a single
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 for feature branches,
On Fri, 25 Feb 2011 13:52:58 +0100
Antoine Pitrou solip...@pitrou.net wrote:
On Fri, 25 Feb 2011 19:13:49 +1100
Neil Hodgson nyamaton...@gmail.com 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
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
in a single
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 using
1 - 100 of 538 matches
Mail list logo
