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

[Chris Angelico]

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 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) will be noticeable. Every time you type 'hg
something', it has to do those imports, so startup time is
significant.

ChrisA
[1] One time I actually did a conversion of CPython from hg into git,
just so I could do some analysis and digging. Worked out considerably
faster, although that's only because I left the import/conversion
process to run by itself while I made a hot chocolate, which meant I
was waiting less time.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Tres Seaver]

-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 understanding of what Matt said at the language summit is that the
need to support really old versions of Python 2.x (back to 2.4) is a big
part of the holdup (straddling is *much* more painful without
constraining to
Python2 = 2.6).

As I heard it, the real reason for the inertia is that the Python3 port
is a lot of effort / pain for zero perceived gain outside of because it
is the Right Thing(TM).  After my porting experience, I can sympathize
with that sensibility, and my stuff gets an advantage (frameworks /
libraries marketing to Python3 devs) that Hg doesn't (most users don't
really care which Python is used to drive the standalone tool).


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlNNVHAACgkQ+gerLs4ltQ4lpwCeJTYvfBBlE3cS+eq+kA4/zEi3
R+8AnRy4HYLRZ4DHhHDop/8A86MJt5Ei
=fORL
-END PGP SIGNATURE-

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Skip Montanaro]

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 imports its own lazy import module. 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.

I'm not trying to be difficult here. I thought that way back in the
day a huge amount of work was done to remove needless filesystem
activity, and zip packaging has been around for quite awhile.

As an experiment, I ran hg pull as

/usr/bin/python -v /usr/bin/hg pull

in my cpython repo then looked at the -v output. Summarizing the
output I saw the following:

30 imports (0 dlopens)

Python banner printed

86 imports (18 dlopens)

adding changesets message

5 imports (2 dlopens)

adding manifests message

1 import (0 dlopens)

adding file changes message

7 imports (3 dlopens)

added ... changesets message

4 imports (0 dlopens)

run 'hg update' message

(I missed a searching message in there somewhere.)

That's a total of 133 imports, 23 of which were satisfied by loading
an extension module. The imports break down as follows:

51 imports (4 dlopens) from the mercurial package
5 imports from the hgext package
7 imports from the encodings package

Everything else is imported from the top level, and at a glance
appears to be all Python stdlib stuff.  The key period of execution
looks to be between the printing of the Python banner and the printing
of the adding changesets message. I see 46 imports (2 dlopens) from
the mercurial or hgext packages. That leaves 40 stdlib imports, of
which 16 were satisfied by dlopen.

As a final check, I saved all the stdlib import statements from the -v
output (77 statements) to a file and timed its execution:

% time /usr/bin/python ~/tmp/pyimp.py

real0m0.162s
user0m0.034s
sys 0m0.010s

It doesn't take much time to import every stdlib module that Mercurial
needs.  I don't know how much slower all this import machinery is in
3.x (and can't test at work, as we don't have a copy laying about). It
would probably have to be 3x or more slower for it to have much
visible impact on even simple hg commands.  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.

Skip
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Skip Montanaro]

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 penalty) will be noticeable.

Based on what I saw, I really don't think that startup slowness is in
imports of Python stdlib modules, which is all Brett was aiming at. I
*can* believe overall import slowness might be a problem, but in that
case, Brett's work isn't going to help the Mercurial folks much.

Skip
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Skip Montanaro]

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.
http://en.wikipedia.org/wiki/Blink If you blink, you've missed
Python 2.7 startup on a relatively modern machine.

wink

Skip
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Chris Angelico]

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 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.


400ms feels glitchy. 100ms is the absolute maximum for immediate
interaction. If I can sense a musical beat between doing something and
seeing its result, it's not instant.

And if there's a comedic beat between them, it's... laughably slow.

*dives for cover*

ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Daniel Holth]

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 speedup.

On Tue, Apr 15, 2014 at 11:34 AM, Skip Montanaro s...@pobox.com wrote:
 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 imports its own lazy import module. 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.

 I'm not trying to be difficult here. I thought that way back in the
 day a huge amount of work was done to remove needless filesystem
 activity, and zip packaging has been around for quite awhile.

 As an experiment, I ran hg pull as

 /usr/bin/python -v /usr/bin/hg pull

 in my cpython repo then looked at the -v output. Summarizing the
 output I saw the following:

 30 imports (0 dlopens)

 Python banner printed

 86 imports (18 dlopens)

 adding changesets message

 5 imports (2 dlopens)

 adding manifests message

 1 import (0 dlopens)

 adding file changes message

 7 imports (3 dlopens)

 added ... changesets message

 4 imports (0 dlopens)

 run 'hg update' message

 (I missed a searching message in there somewhere.)

 That's a total of 133 imports, 23 of which were satisfied by loading
 an extension module. The imports break down as follows:

 51 imports (4 dlopens) from the mercurial package
 5 imports from the hgext package
 7 imports from the encodings package

 Everything else is imported from the top level, and at a glance
 appears to be all Python stdlib stuff.  The key period of execution
 looks to be between the printing of the Python banner and the printing
 of the adding changesets message. I see 46 imports (2 dlopens) from
 the mercurial or hgext packages. That leaves 40 stdlib imports, of
 which 16 were satisfied by dlopen.

 As a final check, I saved all the stdlib import statements from the -v
 output (77 statements) to a file and timed its execution:

 % time /usr/bin/python ~/tmp/pyimp.py

 real0m0.162s
 user0m0.034s
 sys 0m0.010s

 It doesn't take much time to import every stdlib module that Mercurial
 needs.  I don't know how much slower all this import machinery is in
 3.x (and can't test at work, as we don't have a copy laying about). It
 would probably have to be 3x or more slower for it to have much
 visible impact on even simple hg commands.  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.

 Skip
 ___
 Python-Dev mailing list
 Python-Dev@python.org
 https://mail.python.org/mailman/listinfo/python-dev
 Unsubscribe: 
 https://mail.python.org/mailman/options/python-dev/dholth%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Antoine Pitrou]

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 seconds.


Please quote exact versions. Different versions of Python 3 will have 
different startup characteristics.


Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Antoine Pitrou]

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 right. When trying to find out why the hgprompt extension (which 
is a rather nifty extension adding color-coded repository information 
into your bash prompt) made the shell so much slower, it turned out that 
most of the execution time comes from importing *Mercurial* modules, not 
stdlib modules.


Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Stephen J. Turnbull]

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 2.7GHz Core i7:

# Apple's /usr/bin/python, Python 2.7.5, built with clang 5.0.0
$ time python -c   # cold  warm  warm
   real  0.967s0.020s0.022s
   user  0.025s0.011s0.012s
   sys   0.061s0.009s0.007s
# MacPorts /opt/local/bin/python3.3, Python 3.3.5, same compiler
$ time python3.3 -c 
   real  1.034s0.041s0.037s
   user  0.065s0.030s0.028s
   sys   0.036s0.008s0.007s

Further iterations of warm cache starts remain (coincidentally, I
would guess, but it's indicative) in the ranges above.  I don't feel
like rebooting or otherwise figuring out how to evict python from the
cache to get a sense of variation for cold cache startup, but
obviously it's more than an order of magnitude slower than warm start
for both Pythons.

Warm start numbers are well within Daniel's 50ms spec.  Granted user
time for Python 3.3 is 2.5-3X that of Python 2.7 warm or cold, it's
still below human JND (if you can see it, it's probably a slow display
;-).  So it's all about waiting on the OS, it seems to me.

By comparison, git:

$ time git --version  #cold  warm  warm
   real  0.430s0.017s0.021s
   user  0.007s0.006s0.006s
   sys   0.009s0.006s0.006s

OK, Python 2.7 is slower than git and Python 3.3 much slower.  But I
don't think this explains anybody's feeling that hg is sluggish
compared to git -- git also shows perceptible delay on a cold start, I
didn't notice it being faster (I wasn't thinking about it, though, and
I wasn't in a hurry to see the version string).  I suspect Linus has
spiked everybody's Kool-Aid and it's a mass hallucination.  More
seriously, I wouldn't be surprised if git is just better optimized for
certain operations that people expect to be fast.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Daniel Holth]

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 initial speed improvements from git are
fully offset by the feeling of irritation afterwards. /troll

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.

On Tue, Apr 15, 2014 at 12:47 PM, Antoine Pitrou solip...@pitrou.net wrote:
 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 seconds.


 Please quote exact versions. Different versions of Python 3 will have
 different startup characteristics.

 Regards

 Antoine.



 ___
 Python-Dev mailing list
 Python-Dev@python.org
 https://mail.python.org/mailman/listinfo/python-dev
 Unsubscribe:
 https://mail.python.org/mailman/options/python-dev/dholth%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Antoine Pitrou]

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 entire operation
might take. But for me any initial speed improvements from git are
fully offset by the feeling of irritation afterwards. /troll

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.


Well, if we optimize 11% out of that 1/4, I don't expect you to notice 
the speedup at all ;-)


Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Paul Moore]

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 Windows user, the OS
process creation time makes any of the numbers people are quoting for
Unix little more than a pipe dream for me :-)) but it seems to me that
the key measure of sluggishness tends to be on the tiny query
operations (the things people put in their prompt). Nobody cares about
process startup time on a hg clone of a 1GB repo across the network.
But hg status to get details of the current repo to show in your
prompt has to be very fast, or people complain it's slow [1].

On that point, I suspect that git's approach of having a plethora of
tiny focused commands each of which does only what it needs to,
probably makes for a better simple things are fast experience than a
single-application architecture like hg. (On the other hand, it
utterly kills git's performance on Windows, so you win some, you lose
some).

So improving Python startup time will probably help with Mercurial's
*perceived* speed - but architecture improvements focusing on running
enquiry type commands really fast may help as much if not more (I
don't know how much they've optimised for that case in the past).

On 15 April 2014 18:29, Antoine Pitrou solip...@pitrou.net wrote:
 Well, if we optimize 11% out of that 1/4, I don't expect you to notice the
 speedup at all ;-)

Yeah, in reality no one thing is ever going to be *that* perceptible.
But as they say, every little helps.

Paul

[1] Windows process startup times affect this *a lot*. My powershell
prompt function directly reads the files in .hg/.git because running
the actual commands is far too slow for a prompt function.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Daniel Holth]

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 Mercurial or git is a big
 driver in perceived speed as opposed to how long the entire operation
 might take. But for me any initial speed improvements from git are
 fully offset by the feeling of irritation afterwards. /troll

 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.


 Well, if we optimize 11% out of that 1/4, I don't expect you to notice the
 speedup at all ;-)


 Regards

 Antoine.

No one expects the Spanish Inquisition.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Mark Lawrence]

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
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 initial speed improvements from git are
fully offset by the feeling of irritation afterwards. /troll

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.



Well, if we optimize 11% out of that 1/4, I don't expect you to notice the
speedup at all ;-)


Regards

Antoine.


No one expects the Spanish Inquisition.


Except those who expect Python 2.8?

--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Raymond Hettinger]

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 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 approach is fine, but it seems counter-intuitive to the
  whole concept of DVCS.
 
 Perhaps.  But that's exactly what I did with the email package changes
 for 3.3.
 
 You seem to have a tension between all those dirty little commits and
 clean history and the fact that a dvcs is designed to preserve all
 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?
 
 Right.  And you usually have to do this beforehand anyways to upload
 your changes to the tracker for review.
 
 Also, for the record (not that anyone has said anything to the
 contrary), our dev guide says, You should collapse changesets of a
 single feature or bugfix before pushing the result to the main
 repository. The reason is that we don’t want the history to be full of
 intermediate commits recording the private history of the person
 working on a patch. If you are using the rebase extension, consider
 adding the --collapse option to hg rebase. The collapse extension is
 another choice.
 
 (from http://docs.python.org/devguide/committing.html#working-with-mercurial )


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.


Raymond
___
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...

[Tim Delaney]

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...

[Tim Delaney]

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 each collapsed changeset is for a single change I
haven't seen this be a major issue. However, I'm personally a create a new
named branch for each task, keep all intermediate history kind of guy (and
I get to set the rules for my team ;) so I don't see collapsed changesets
very often.

Tim Delaney


On 17 December 2012 16:17, Raymond Hettinger raymond.hettin...@gmail.comwrote:


 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 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 approach is fine, but it seems counter-intuitive to the
   whole concept of DVCS.
 
  Perhaps.  But that's exactly what I did with the email package changes
  for 3.3.
 
  You seem to have a tension between all those dirty little commits and
  clean history and the fact that a dvcs is designed to preserve all
  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?
 
  Right.  And you usually have to do this beforehand anyways to upload
  your changes to the tracker for review.
 
  Also, for the record (not that anyone has said anything to the
  contrary), our dev guide says, You should collapse changesets of a
  single feature or bugfix before pushing the result to the main
  repository. The reason is that we don’t want the history to be full of
  intermediate commits recording the private history of the person
  working on a patch. If you are using the rebase extension, consider
  adding the --collapse option to hg rebase. The collapse extension is
  another choice.
 
  (from
 http://docs.python.org/devguide/committing.html#working-with-mercurial )


 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.


 Raymond
 ___
 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/timothy.c.delaney%40gmail.com

___
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...

[Stephen J. Turnbull]

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 explanation is correct as far as it goes.

But I would give a pretty firm No as the answer to your question.

The big difference between svn (and CVS) and hg (and git and bzr) at
the time of migrating the Python repository was that svn didn't track
merges, only branches.  So in svn you get a 3-way merge with the
branch point as the base version.  This meant that you could not track
progress of the mainline while working on a branch.  svn tends to
report the merge of recent mainline changes back into the mainline as
conflicts when merging your branch into the mainline[1][2], all too
often resulting in a big mess.

hg, because it records merges as well as branches, can use the most
recent common version (typically the mainline parent of the most
recent catch-up merge) as the base version.  This means that (1)
there are somewhat fewer divergences because your branch already
contains most changes to the mainline, and (2) you don't get
spurious conflicts.  On the other hand, more frequent intermediate
committing is mostly helpful in bisection, and so the usefulness
depends on very disciplined committing (only commit build- and
test-able code).

Summary: only the frequency of intermediate merge commits really
matters.  Because in hg it's possible to have frequent catch-up
merges from mainline, you get smaller merges with fewer conflicts both
at catch-up time and at merge-to-mainline time.


Footnotes: 
[1]  Not the whole story, but OK for this purpose.  Technical details
available on request.

[2]  I have paid almost no attention to svn since Python migrated to
hg, so perhaps svn has improved merge support in the meantime.  But
that doesn't really matter since svn is merely being used to help
explain why commit granularity doesn't matter much to hg's merge
capabilities.

___
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...

[Antoine Pitrou]

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
  ready, then apply that diff to the main cpython repo, then push
  that. This approach is fine, but it seems counter-intuitive to the
whole concept of DVCS.
 
 Perhaps.  But that's exactly what I did with the email package changes
 for 3.3.
 
 You seem to have a tension between all those dirty little commits
 and clean history and the fact that a dvcs is designed to preserve
 all 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?  If you keep your pulls up to date in your feature repo, the
 diff/patch process is simple and smooth.

+1.  We definitely don't want tons of small incremental commits in the
official repo.  One changeset == one issue should be the ideal horizon
when committing changes.

Regards

Antoine.


___
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

[Python-Dev] Mercurial workflow question...

[Trent Nelson]

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 happy with the change.  So,
it's time to do all the necessary cruft that needs to be done before
making the change public.  Updating docs, tweaking style, Misc/NEWS,
etc.  That'll involve at least a few more commits.  Most changes
will also need to be merged to other branches, too, so that needs to
be taken care of.  (And it's a given that I would have been pulling
and merging from hg.p.o/cpython during the whole process.)

Then, finally, it's time to push.

Now, if I understand how Mercurial works correctly, using the above
workflow will result in all those little intermediate hacky commits
being forever preserved in the global/public cpython repo.  I will
have polluted the history of all affected files with all my changes.

That just doesn't feel right.  But, it appears as though it's an
intrinsic side-effect of how Mercurial works.  With git, you have a
bit more flexibility to affect how your final public commits via
merge fast-forwarding.  Subversion gives you the ultimate control of
how your final commit looks (albeit at the expense of having to do
the merging in a much more manual fashion).

As I understand it, even if I contain all my intermediate commits in
a server-side cloned repo, that doesn't really change anything; all
commits will eventually be reflected in cpython via the final `hg
push`.

So, my first question is this: is this actually a problem?  Is the
value I'm placing on pristine log histories misplaced in the DVCS
world?  Do we, as a collective, care?

I can think of two alternate approaches I could use:

- Use a common NFS mount for each source tree on every Snakebite
  box (and coercing each build to be done in a separate area).
  Get everything perfect and then do a single commit of all
  changes.  The thing I don't like about this approach is that
  I can't commit/rollback/tweak/bisect intermediate commits as
  I go along -- some changes are complex and take a few attempts
  to get right.

- 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 approach is fine, but it seems counter-intuitive to the
  whole concept of DVCS.

Thoughts?


Trent.
___
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...

[Larry Hastings]

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/archive%40mail-archive.com

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

[Nick Coghlan]

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
ones you want to publish and provide tools to revise a series of commits
into a simpler set for publication to an official repo. The difference is
that in Git this is allowed by default for all branches (which can create
fun and games if someone upstream of you edits the history of you branch
you used as a base for your own work), while Hg makes a distinction between
different phases (secret - draft - public) and disallows operations that
rewrite history if they would affect public changesets.

So the challenge with Mercurial over Git is ensuring the relevant branches
stay in draft mode locally even though you want to push them to a
server-side clone for distribution to the build servers. I know one way to
do that would be to ask that the relevant clone be switched to
non-publishing mode (see
http://mercurial.selenic.com/wiki/Phases#Publishing_Repository). I don't
know if there's another way to do it without altering the config on the
server.

General intro to phases: http://www.logilab.org/blogentry/88203

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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...

[R. David Murray]

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.
   This approach is fine, but it seems counter-intuitive to the
   whole concept of DVCS.

Perhaps.  But that's exactly what I did with the email package changes
for 3.3.

You seem to have a tension between all those dirty little commits and
clean history and the fact that a dvcs is designed to preserve all
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?  If
you keep your pulls up to date in your feature repo, the diff/patch
process is simple and smooth.

The repo I worked on the email features in is still available, too, if
anyone is crazy enough to want to know about those intermediate steps...

--David
___
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...

[Chris Jerdonek]

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 ready,
   then apply that diff to the main cpython repo, then push that.
   This approach is fine, but it seems counter-intuitive to the
   whole concept of DVCS.

 Perhaps.  But that's exactly what I did with the email package changes
 for 3.3.

 You seem to have a tension between all those dirty little commits and
 clean history and the fact that a dvcs is designed to preserve all
 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?

Right.  And you usually have to do this beforehand anyways to upload
your changes to the tracker for review.

Also, for the record (not that anyone has said anything to the
contrary), our dev guide says, You should collapse changesets of a
single feature or bugfix before pushing the result to the main
repository. The reason is that we don’t want the history to be full of
intermediate commits recording the private history of the person
working on a patch. If you are using the rebase extension, consider
adding the --collapse option to hg rebase. The collapse extension is
another choice.

(from http://docs.python.org/devguide/committing.html#working-with-mercurial )

--Chris
___
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...

[Barry Warsaw]

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 that it has a concept of main line
of development that usually makes all this hand-wringing a non-issue.  When I
merge my development branch, with all its interim commits into trunk, all
those revisions go with it.  But it never matters because when you view
history (and bisect, etc.) on trunk, you see the merge as one commit.

Sure, you can descend into the right-hand side if you want to see all those
sub-commits, and the graphical tools allow you to expand them fairly easily,
but usually you just ignore them.

Nothing's completely for free of course, and having a main line of development
does mean you have to be careful about merge directionality, but that's
generally something you ingrain in your workflow once, and then forget about
it.  The bottom line is that Bazaar users rarely feel the need to rebase, even
though you can if you want to.

Cheers,
-Barry


signature.asc
Description: PGP signature
___
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...

[Ned Deily]

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 the final commit is ready,
then apply that diff to the main cpython repo, then push that.
This approach is fine, but it seems counter-intuitive to the
whole concept of DVCS.
 
 Perhaps.  But that's exactly what I did with the email package changes
 for 3.3.
 
 You seem to have a tension between all those dirty little commits and
 clean history and the fact that a dvcs is designed to preserve all
 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?  If
 you keep your pulls up to date in your feature repo, the diff/patch
 process is simple and smooth.

Also, if you prefer to go the patch route, hg provides the mq extension 
(inspired by quilt) to simplify managing patches including version 
controlling the patches.  I find it much easy to deal that way with 
maintenance changes that may have a non-trivial gestation period.

-- 
 Ned Deily,
 n...@acm.org

___
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...

[Stephen J. Turnbull]

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,
dice, and mince the patches at the hunk level.  Presenting the logic
of the change often is best done in pieces but in an ahistorical way,
but debugging often benefits from the context of an exact sequential
history.

That said, diff/patch across repos is not per se evil, and may be
easier for users to visualize than the results of the DAG
transformations (such as rebase) provided by existing dVCSes.

___
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

[Python-Dev] Mercurial workflow: merging from 3.2

[Michael Foord]

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 as 
these unmerged changesets appear as conflicts.


If you do work in 3.2 (or earlier) please merge those changesets to default.

All the best,

Michael

--
http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html

___
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 conversion repositories

[Santoso Wijaya]

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
? PC/pythonnt_rc_d.h



~/santa


On Mon, Feb 28, 2011 at 1:10 PM, Antoine Pitrou solip...@pitrou.net wrote:

 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 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 place (i.e. repository) to stash these useful add-ons
 and
   hacks so that all Python developers can find them.
  
  I think you can simply add them somewhere on the hg wiki:
  http://mercurial.selenic.com/wiki/
  and then link to the pages from our own wiki, or the developer's FAQ.
 
  If they're of general use to the hg community, sure.  Otherwise, it might
 be
  good to have a place of our own for our own repository tools.

 Well, your diff-in-the-commit-editor-window is certainly not
 CPython-specific ;)

 Regards

 Antoine.


 ___
 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/santoso.wijaya%40gmail.com

___
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 conversion repositories

[Martin v. Löwis]

 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 go to the bug tracker. If you host a clone somewhere,
you could start publishing patches by referring to a remote repository,
rather than uploading the diff. I'm curious how this DVCS thing works
out for contributors.

Regards,
Martin
___
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 conversion repositories

[Santoso Wijaya]

 [...] 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 mar...@v.loewis.dewrote:

  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 go to the bug tracker. If you host a clone somewhere,
 you could start publishing patches by referring to a remote repository,
 rather than uploading the diff. I'm curious how this DVCS thing works
 out for contributors.

 Regards,
 Martin

___
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 conversion repositories

[Antoine Pitrou]

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 experimentation? 

Pragmatically, I think we would still prefer patches, but Mercurial
should make it much easier to maintain them - e.g. you can use mq (which
is what Mercurial devs themselves use, actually).

We can also experiment with other forms of publishing changes, but I
think that would require the publisher to somehow collapses their own
changesets, so that it finally amounts to reviewing a patch.  In my
opinion at least, it would be bad if we started integrating intermediate
changesets leading to a final patch just because Mercurial allows us to
do it. I think it's better if the public history line doesn't get
obscured with work-in-progress changesets.

Regards

Antoine.


___
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 conversion repositories

[Barry Warsaw]

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 course it would be nice if hg made it easier (a hgrc option, for example)
to do this.

Sure.

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 place (i.e. repository) to stash these useful add-ons and
hacks so that all Python developers can find them.

-Barry



signature.asc
Description: PGP signature
___
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 conversion repositories

[Antoine Pitrou]

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 find a place (i.e. repository) to stash these useful add-ons and
 hacks so that all Python developers can find them.

I think you can simply add them somewhere on the hg wiki:
http://mercurial.selenic.com/wiki/
and then link to the pages from our own wiki, or the developer's FAQ.

Regards

Antoine.


___
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 conversion repositories

[Barry Warsaw]

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 hgeditor.  The extension had 10 lines of code.
 
 We should find a place (i.e. repository) to stash these useful add-ons and
 hacks so that all Python developers can find them.

I think you can simply add them somewhere on the hg wiki:
http://mercurial.selenic.com/wiki/
and then link to the pages from our own wiki, or the developer's FAQ.

If they're of general use to the hg community, sure.  Otherwise, it might be
good to have a place of our own for our own repository tools.

-Barry



signature.asc
Description: PGP signature
___
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 conversion repositories

[Antoine Pitrou]

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 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 place (i.e. repository) to stash these useful add-ons and
  hacks so that all Python developers can find them.
 
 I think you can simply add them somewhere on the hg wiki:
 http://mercurial.selenic.com/wiki/
 and then link to the pages from our own wiki, or the developer's FAQ.
 
 If they're of general use to the hg community, sure.  Otherwise, it might be
 good to have a place of our own for our own repository tools.

Well, your diff-in-the-commit-editor-window is certainly not
CPython-specific ;)

Regards

Antoine.


___
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 conversion repositories

[Antoine Pitrou]

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 default branch (which is
  omitted for concision by hg log and other commands with a similar
  output).
 
 It's probably a terminology issue, but: the changeset can't be on
 the default branch, because the head of the default branch (called
 tip, IIUC) isn't a descendant of that changeset.

Well, a branch (or named branch) in hg terminology can have several
heads (see the other email about heads and branches).

Also, just so you know, tip is simply the latest (in pull or commit
order) changeset in the local repository. It can be in any branch (for
example, if you pull of bunch of changesets someone made in 3.2,
then your tip will be in branch 3.2).

I hope it all starts to make sense ;)

Regards

Antoine.
___
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 conversion repositories

[Georg Brandl]

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 want it to (hg 1.6.3).  It opens your
 editor with two files, one is the commit message and the other is the diff.
 (The script itself is a bit buggy too. ;)
 
 But it's a good clue, and I've modified the default hgeditor script to get
 closer, and fix the bug I noticed.  I basically append the diff to the
 temporary log message file.  It's still not right though because if the diff
 lines aren't prepended with 'HG:', they end up in the commit message.  Arg.
 
 Oh well, I can clearly hack a more complicated script together.  It's such a
 blindingly obvious improvement, it's too bad 'hg commit' doesn't DTRT by
 default.

While I understand the usefulness of the diff feature, it is not useful to
everyone, e.g. those using almost exclusively ``commit -m message``.

Of course it would be nice if hg made it easier (a hgrc option, for example)
to do this.

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.

Georg

___
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 conversion repositories

[Stephen J. Turnbull]

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.


___
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 conversion repositories

[Martin v. Löwis]

 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 will ask, and every other person will know.

Regards,
Martin
___
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 conversion repositories

[Ethan Furman]

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.768010:8174d00d0797
   3.167955:5be8b695ea86
   2.667287:5e26a860eded
   2.565464:e4ecac76e499
   trunk  62750:800f6c92c3ed
   3.060075:1d05144224fe
   2.458552:df72cac1899e
   2.345731:a3d9a9730743
   2.240444:d55ddc8c8501
   2.130171:06fcccf6eca8
   2.018214:dc0dfc9565cd

The branch default is the current py3k branch from SVN. The branch
trunk represents SVN trunk history until 2.7 was branched for
maintenance.

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.


That was my first idea, but then I realized that the branch includes 1.x
and even pre-1.0 commits, so 2.x might actually be more
confusing/misleading and hide the fact that the full trunk history is
there.


Maybe prePy3k, then?  Trunk, after all, is not very descriptive.  Or is 
that name also inaccurate?


~Ethan~
___
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 conversion repositories

[Nick Coghlan]

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 :)

In that case, legacy-trunk would seem clearer.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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 conversion repositories

[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, for a non-native English
 speaker).

 +1. People will recognize trunk as a svn think. If that doesn't
 clue them in, they will ask, and every other person will know.

But why not choose a name where they don't even have to ask?

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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 conversion repositories

[Antoine Pitrou]

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 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 will ask, and every other person will know.
 
 But why not choose a name where they don't even have to ask?

Doesn't trunk represent exactly what it is (the former SVN trunk)?
Other names would probably be less exact or less precise.

Regards

Antoine.


___
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 conversion repositories

[Michael Foord]

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 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 will ask, and every other person will know.

But why not choose a name where they don't even have to ask?

Doesn't trunk represent exactly what it is (the former SVN trunk)?
Other names would probably be less exact or less precise.


Well, except for the prevalence of trunk as terminology to mean place 
where current development happens. It will lead to odd conversations 
like:  is trunk the trunk?, no trunk is what used to be trunk, 
default is now trunk.


Renaming it legacy-trunk is no less precise, but more explicative.

Michael


Regards

Antoine.


___
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/fuzzyman%40voidspace.org.uk



--
http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html

___
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 conversion repositories

[Antoine Pitrou]

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
   /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 will ask, and every other person will know.
  
  But why not choose a name where they don't even have to ask?
 
 Doesn't trunk represent exactly what it is (the former SVN trunk)?
 Other names would probably be less exact or less precise.

Although I now admit legacy-trunk sounds quite accurate, and conveys
a clear warning to anyone wondering if they should use it.

Regards

Antoine.


___
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 conversion repositories

[Martin v. Löwis]

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, for a non-native English
 speaker).

 +1. People will recognize trunk as a svn think. If that doesn't
 clue them in, they will ask, and every other person will know.
 
 But why not choose a name where they don't even have to ask?

That could be better. Unfortunately, nobody has proposed a name
that has this property and is also correct.

Regards,
Martin
___
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 conversion repositories

[Martin v. Löwis]

 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 especially a tree remaining
attached to the root after the trunk is cut
___
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 conversion repositories

[Daniel Stutzbach]

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 a strict subset
of the 2.7 branch's history, isn't it?

-- 
Daniel Stutzbach
___
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 conversion repositories

[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 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 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 ;)
(in other words: 2.7 starts where trunk stops; trunk changesets are
strict ancestors of 2.7)

Regards

Antoine.


___
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 conversion repositories

[Éric Araujo]

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 both
trunk and py3k were active, it would create two unnamed branches on the
default branch, but one merge would solve that.

Regards
___
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 conversion repositories

[Antoine Pitrou]

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 each other ;)
 
 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, especially if they try a graphical display of
the DAG (e.g. hg glog or the graph page in the Web UI).

Besides, it would precisely make it harder to distinguish between
trunk and py3k development at the time both took place in parallel.

Regards

Antoine.


___
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 conversion repositories

[Nick Coghlan]

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 from hg commands, I'm fine with keeping the old trunk
name from SVN. It was only when those commands were displaying both
trunk and default that it bothered me.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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 conversion repositories

[Éric Araujo]

 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, especially if they try a graphical display of
 the DAG (e.g. hg glog or the graph page in the Web UI).

The dummy merge would not stay long: The commits targeted at 3.3 would
be its children.

 Besides, it would precisely make it harder to distinguish between
 trunk and py3k development at the time both took place in parallel.

IIUC, there would be two parallel lines of history (unnnamed branches).
 Would that be hard to read?

Regards
___
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 conversion repositories

[Daniel Stutzbach]

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 can't be a subset of each other ;)
 (in other words: 2.7 starts where trunk stops; trunk changesets are
 strict ancestors of 2.7)


Maybe I don't fully understand how Mercurial branches work or how it defines
terminology (in fact, that is likely :) ).  What's the difference between
the statement trunk changesets are strict ancestors of 2.7 and the
statement trunk's history is a strict subset of 2.7's history?

-- 
Daniel Stutzbach
___
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 conversion repositories

[Éric Araujo]

 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 is to say, someone pulling default also gets the
changesets from stable that are ancestors of the merge changset.  Or in
other words, if you check out default, you get all bug fixes from stable.

HTH
___
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 conversion repositories

[Antoine Pitrou]

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 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 ;)
 (in other words: 2.7 starts where trunk stops; trunk
 changesets are
 strict ancestors of 2.7)
 
 
 Maybe I don't fully understand how Mercurial branches work or how it
 defines terminology (in fact, that is likely :) ).  What's the
 difference between the statement trunk changesets are strict
 ancestors of 2.7 and the statement trunk's history is a strict
 subset of 2.7's history?

Apparently you overlooked the first statement:
Named branches are exclusive.
In other words, a changeset can be in only one named branch.
So it's impossible for a branch to be a subset or superset of another.
(except the trivial case of an empty branch :-)).



___
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 conversion repositories

[Martin v. Löwis]

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 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 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 ;)
 (in other words: 2.7 starts where trunk stops; trunk changesets are
 strict ancestors of 2.7)

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?

I'd like to prevent people from mistakenly committing onto the trunk,
which would be easiest if trunk didn't exist at all.

Regards,
Martin
___
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 conversion repositories

[Antoine Pitrou]

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 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 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 ;)
  (in other words: 2.7 starts where trunk stops; trunk changesets are
  strict ancestors of 2.7)
 
 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?

 I'd like to prevent people from mistakenly committing onto the trunk,
 which would be easiest if trunk didn't exist at all.

Well, the push you request in the todo should do the trick.
We can also call it legacy-trunk, too :)

Regards

Antoine.


___
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 conversion repositories

[Barry Warsaw]

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 default
 push/pull path to point to ssh://h...@hg.python.org/cpython instead, you'd
 want to edit the [paths] section in the .hg/hgrc file in each of the
 branch repos.

I plan on having one clone per branch but pushing and pulling from only
one repository, so I don’t need to edit hgrcs.

So let's start from the basics.  I want separate working directories for each
active line-of-development (I'll use that term instead of branch),
e.g. working directories containing the tip of the 2.6 LoD, 2.7, 3.1, 3.2, and
3.3.  I will not be doing feature or bug development in any of these
directories.  They are purely for local tracking of the remote masters.  Thus,
I want to be able to synchronize any one of those LoDs against the remote
master with one command, like I would using Subversion's 'svn up'.

I clone the remote repository using the command in the devguide, so I now have
a 'cpython' directory containing the history of all LoDs, but with a working
directory that reflects the 'default' LoD.  Now, in the parent of 'cpython', I
do the following to get my separate-directory-LoDs:

$ hg clone -u 2.6 cpython py26
$ hg clone -u 2.7 cpython py27
# repeat and rinse for all other active LoDs

(Aside: that cpython directory still bugs me.  It doesn't naturally reflect a
LoD, so why do I have to stare at it?  Yes, I can make it play double duty by
naming it 3.3 or whatever and updating it to the 3.3 LoD, but that feels
artificial.)

Now I want to synchronize my local py27 directory with the state of that LoD
on python.org.  This is a two step process:

$ cd py27 # now I want to synchronize
$ (cd ../cpython  hg pull)
$ hg pull -u

Editing hgrc to point to hg.python.org means the sync-to-remote-master
operation is one command.

I could do this:

$ 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 does.

Anecdote: I migrated from Subversion to Mercurial a few years ago, and
found Mercurial branches very intuitive.  When I saw mentions of Bazaar
branches I was driven nuts by (what I saw as) the conflation between a
branch and a clone.  Later I understood how it made sense from the
perspective of Bazaar, so I shifted my judgment from “insanely
confusing” to “a particular choice that I don’t approve” wink.

That's funny because to my eyes, Mercurial conflates branches and clones.
Why a clone operation should give me the history for all lines-of-development
inside a working directory for one arbitrary one strikes me as bizarre
(pardon the pun :).  I get that for folks who like the svn switch method of
working on multiple LoDs, this probably makes a lot of sense.  I don't
personally like or trust that approach much though.

What I’m saying is that a lot of Bazaar terminology using “branch” does
not map as-is to Mercurial.  We clone a repo, we pull from a repo/clone,
we have named branches (e.g. 3.2) in a repo, we have unnamed branches on
one named branch.  I think you know that already, since you went from
using Bazaar terms applied to Mercurial to mixing terms from both
(“clone a new branch working directory” → “clone a repo”, probably).  I
salute your willingness to learn Mercurial, considering how fluent (and
fluffly) you appear to be with Bazaar.

This is an inevitable problem with trying to converse fluently about three
major dVCSs and at least one or two other non-dVCSs.  They all use the same
words to mean vaguely similar things, but quickly get bogged down in the
implementation details assigned to those words.  It all makes perfect sense
when you've been immersed in those technologies, but it makes discussions and
comparisons exceedingly difficult.  I've no doubt it's doubly painful to many
people who have no prior experience with a dVCS.

(Aside: Bazaar could have potentially eased these folks transition because you
can use Bazaar just like you would Subversion - as a centralized VCS --
without stopping others from using it with full dVCS features on the same code
base.  I don't know if Mercurial offers the same flexibility.)

It's a little like trying to teach Python to a Java programmer.  Object,
Class, Instance, Import all mean roughly similar things, which lulls you
into a false sense of understanding.  We learn by holding up the new to the
light of the familiar and looking for interference patterns. :)

 I'll have to remember that 'hg pull' does not update the working copy by
 default,

That pull does not update is a feature: The operation between a remote
repo and the local repo (the .hg directory) is separate from the
operation from the local 

Re: [Python-Dev] Mercurial conversion repositories

[Martin v. Löwis]

 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 list unnamed branches. hg heads omits any branch
name for unnamed branches. See the cpythonextras repository for examples:

changeset:   72694:e65daae6cf44
user:Antoine Pitrou solip...@pitrou.net
date:Mon Feb 21 21:30:55 2011 +
summary: Try s/UINT_MAX/INT_MAX/

This is listed as a head, but not of a named branch.

 I'd like to prevent people from mistakenly committing onto the trunk,
 which would be easiest if trunk didn't exist at all.
 
 Well, the push you request in the todo should do the trick.

Yes, that would also work. However, when then somebody proposed that
we may not need the trunk branch at all in the conversion result
(which I still think is the case - we don't need it), I noticed
that this would solve the problem in a more clean manner.

 We can also call it legacy-trunk, too :)

I think we can do better. I also dislike hg log --only-branch default
to only go back to 2006 (to aeefba456e4d), when this revision actually
does have a parent (namely, on the trunk branch, 4b41806a0326).

So I would propose this attribution to branches:
- everything that is ancestor of the default branch is attributed
  to the default branch, back to the very beginning of the repository.
- Everything currently on trunk that wouldn't be on default is then
  attributed to the oldest branch that it is an ancestor of, in the
  order 2.0, 2.1, 2.2, ... 2.7.

So e.g. the 2.7 branch would go back to where it branched from the 2.6
branch (after the actual creation of the 2.6 branch in svn), which
would go back to where it branched from 2.5, and so on.

Regards,
Martin
___
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 conversion repositories

[Barry Warsaw]

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 commit, default becomes a superset of
stable.  That is to say, someone pulling default also gets the
changesets from stable that are ancestors of the merge changset.  Or in
other words, if you check out default, you get all bug fixes from stable.

That makes sense, but correct me if I'm wrong, it's the 'merge' operation that
made this happen, right?  A merge essentially brings the changesets from one
branch into another.

-Barry


signature.asc
Description: PGP signature
___
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 conversion repositories

[Antoine Pitrou]

  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 list unnamed branches. hg heads omits any branch
 name for unnamed branches. See the cpythonextras repository for examples:
 
 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 similar
output).

  I'd like to prevent people from mistakenly committing onto the trunk,
  which would be easiest if trunk didn't exist at all.
  
  Well, the push you request in the todo should do the trick.
 
 Yes, that would also work. However, when then somebody proposed that
 we may not need the trunk branch at all in the conversion result
 (which I still think is the case - we don't need it), I noticed
 that this would solve the problem in a more clean manner.

But you *need* the changesets from the trunk branch. You are just
arguing for giving them another label (including  or default),
hence:

  We can also call it legacy-trunk, too :)
 
 I think we can do better. I also dislike hg log --only-branch default
 to only go back to 2006 (to aeefba456e4d), when this revision actually
 does have a parent (namely, on the trunk branch, 4b41806a0326).

I'm not convinced that small quirks of using hg log are important at
this point. Also, you could try other options of hg log such as
--follow.

If we called ex-trunk the same name as ex-py3k (default), things would
probably be quite more confusing, since inspecting a changeset wouldn't
tell you immediately where it comes from (2.x or 3.x development).

Regards

Antoine.


___
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 conversion repositories

[Daniel Stutzbach]

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. at
http://mercurial.selenic.com/wiki/BranchingExplained

But as I dig deeper, I see that there is only one unnamed branch, and it
actually does have an implicit name: default.

It appears Mercurial supports at least three different kinds of branching:
cloning (similar to Bazaar), bookmarks (similar to git), and named branches.
 So a named branch can contain more than one branch.

Were there reasons for going with named branches over bookmarks?  PEP 385
discusses only cloning and named branches.  I'm just curious, not trying to
start a long discussion. :-)

-- 
Daniel Stutzbach
___
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 conversion repositories

[Santoso Wijaya]

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:

 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 commit, default becomes a superset of
 stable.  That is to say, someone pulling default also gets the
 changesets from stable that are ancestors of the merge changset.  Or in
 other words, if you check out default, you get all bug fixes from stable.

 That makes sense, but correct me if I'm wrong, it's the 'merge' operation
 that
 made this happen, right?  A merge essentially brings the changesets from
 one
 branch into another.

 -Barry

 ___
 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/santoso.wijaya%40gmail.com


___
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 conversion repositories

[Santoso Wijaya]

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 here. Bookmarks are really for
potential branches, experimental features, for example, for easier
navigation for the developer's convenience. Named branches, on the other
hand, are better for posterity reasons.

~/santa


On Sat, Feb 26, 2011 at 10:40 AM, Daniel Stutzbach stutzb...@google.comwrote:

 On Sat, Feb 26, 2011 at 9:55 AM, Antoine Pitrou solip...@pitrou.netwrote:

 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://mercurial.selenic.com/wiki/BranchingExplained

 But as I dig deeper, I see that there is only one unnamed branch, and it
 actually does have an implicit name: default.

 It appears Mercurial supports at least three different kinds of branching:
 cloning (similar to Bazaar), bookmarks (similar to git), and named branches.
  So a named branch can contain more than one branch.

 Were there reasons for going with named branches over bookmarks?  PEP 385
 discusses only cloning and named branches.  I'm just curious, not trying to
 start a long discussion. :-)

 --
  Daniel Stutzbach

 ___
 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/santoso.wijaya%40gmail.com


___
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 conversion repositories

[R. David Murray]

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 it :) Bazaar does.

How does setting it in the hgrc differ from remebering it?  I've never
been comfortable with the bzr --remember option because I'm never
sure what it is remembering.  Much easier for me to see it in a config
file.  But, then, that's how my brain works, and other people's will
work differently.

 On Feb 26, 2011, at 01:49 AM, Éric Araujo wrote:
 Anecdote: I migrated from Subversion to Mercurial a few years ago, and
 found Mercurial branches very intuitive.  When I saw mentions of Bazaar
 branches I was driven nuts by (what I saw as) the conflation between a
 branch and a clone.  Later I understood how it made sense from the
 perspective of Bazaar, so I shifted my judgment from “insanely
 confusing” to “a particular choice that I don’t approve” wink.
 
 That's funny because to my eyes, Mercurial conflates branches and clones.
 Why a clone operation should give me the history for all lines-of-development
 inside a working directory for one arbitrary one strikes me as bizarre
 (pardon the pun :).  I get that for folks who like the svn switch method of
 working on multiple LoDs, this probably makes a lot of sense.  I don't
 personally like or trust that approach much though.

I agree with you that I don't trust the 'svn switch' style.  I also find
it slow.  However

 That pull does not update is a feature: The operation between a remote
 repo and the local repo (the .hg directory) is separate from the
 operation from the local repo to the working directory.  When you know
 that you want pull + update (like when you have a clean working
 directory), you use “hg pull -u”.  (I don’t like the fetch command.)
 
 Sure, I get that.  Again, this feature appears odd because I have the full
 history of all LoDs embedded in a working directory of a single LoD.  With the
 arrangement I outlined above (which is independent of the dVCS backing it), it
 makes no sense for each LoD working directory to contain all the history of
 all the other LoDs.
 
 In Bazaar, a branch is an independent LoD and it's repository contains
 only its own history.  Sure, it might have identical history with other LoDs
 up to the point of divergence, and I have ways to efficiently share that
 history across multiple LoD working directories, but they are still separate
 and I don't need them if I don't care about them.  With Mercurial, all history
 for all LoDs in a repository always come along for the ride.

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 working copy, and that the repository is *the*
repository.  That is, it has everything related to the project in it,
just like the master SVN repository does (plus, since it is a DVCS,
whatever I've committed locally but not pushed to the master).  To have
a repository that only has some of the stuff in it is, IMO, confusing.
I advocated for having all the Python history in one repo partly for
that reason.

I can intellectually see your point about not really *needing* the stuff
for the LODs if you are only working on LOD X, but just like 'svn switch'
makes me uncomfortable, I'm just not *comfortable* not having the whole
repo in there :)

As an example, with mercurial, I feel comfortable moving directories
around and renaming them (with the help of google it took me about 1
minute to figure out how to keep the association between the repository
instances intact).  With bazaar I got in trouble trying to do that,
because the interrelationship between the working copy directories
(and their subsets of the repo?) and the master repo(?) was not clear.
I never did figure out how to make it work, I ended up starting over
with a new clone.

Now, as I get farther into learning mercurial I may well find things that
are just as confusing as I found that aspect of bazaar, but at least I
am comfortable with the outermost layer: the repo is the repo is the repo.

--
R. David Murray  www.bitdance.com
___
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 conversion repositories

[Brett Cannon]

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 I'm afraid. :)

 You can even select indvidually inside a file which lines to commit or
 not. A bit risky but very handy when you have a few oneliners to commit
 or not to commit.

 You mean, TortoiseHg supports incremental commits on a single file?  That's
 kind of neat, but scary. ;)


The record extension lets regular Mercurial do that as well. I think git
supports a similar thing.

-Brett



 -Barry

 ___
 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/brett%40python.org


___
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 conversion repositories

[Brett Cannon]

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 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...@hg.python.org/cpython instead,
 you'd
  want to edit the [paths] section in the .hg/hgrc file in each of the
  branch repos.
 
 I plan on having one clone per branch but pushing and pulling from only
 one repository, so I don’t need to edit hgrcs.

 So let's start from the basics.  I want separate working directories for
 each
 active line-of-development (I'll use that term instead of branch),
 e.g. working directories containing the tip of the 2.6 LoD, 2.7, 3.1, 3.2,
 and
 3.3.  I will not be doing feature or bug development in any of these
 directories.  They are purely for local tracking of the remote masters.
  Thus,
 I want to be able to synchronize any one of those LoDs against the remote
 master with one command, like I would using Subversion's 'svn up'.


For other people's benefit, LoD == line of development (I think).



 I clone the remote repository using the command in the devguide, so I now
 have
 a 'cpython' directory containing the history of all LoDs, but with a
 working
 directory that reflects the 'default' LoD.  Now, in the parent of
 'cpython', I
 do the following to get my separate-directory-LoDs:

 $ hg clone -u 2.6 cpython py26
 $ hg clone -u 2.7 cpython py27
 # repeat and rinse for all other active LoDs


That's one way of doing it.


 (Aside: that cpython directory still bugs me.  It doesn't naturally reflect
 a
 LoD, so why do I have to stare at it?  Yes, I can make it play double duty
 by
 naming it 3.3 or whatever and updating it to the 3.3 LoD, but that feels
 artificial.)


It's a clone repository of CPython; the name makes perfect sense. You are
focusing on what the repository happens to be updated to ATM, not the fact
that the repository itself represents any and all LoDs.



 Now I want to synchronize my local py27 directory with the state of that
 LoD
 on python.org.  This is a two step process:

 $ cd py27 # now I want to synchronize
 $ (cd ../cpython  hg pull)
 $ hg pull -u

 Editing hgrc to point to hg.python.org means the sync-to-remote-master
 operation is one command.

 I could do this:

 $ 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
 does.


So does Hg: simply edit your .hgrc to have it both pull and push to the same
URL.

Or you can save yourself some trouble, and simply clone the repository at a
specific branch:

  hg clone ssh://h...@hg.python.org/cpython#2.7

I believe that might even strip out other history outside the scope of the
branch.



 Anecdote: I migrated from Subversion to Mercurial a few years ago, and
 found Mercurial branches very intuitive.  When I saw mentions of Bazaar
 branches I was driven nuts by (what I saw as) the conflation between a
 branch and a clone.  Later I understood how it made sense from the
 perspective of Bazaar, so I shifted my judgment from “insanely
 confusing” to “a particular choice that I don’t approve” wink.

 That's funny because to my eyes, Mercurial conflates branches and
 clones.
 Why a clone operation should give me the history for all
 lines-of-development
 inside a working directory for one arbitrary one strikes me as bizarre
 (pardon the pun :).


Because Hg views a clone as that: a clone of the entire repository. A branch
just happens to be a part of the repository. And because it is the entire
repository it has to have you point somewhere, so it goes with default since
a lot of people never even work somewhere other than on default.


  I get that for folks who like the svn switch method of
 working on multiple LoDs, this probably makes a lot of sense.  I don't
 personally like or trust that approach much though.


Neither do I in an svn context and why Hg does let you check out just a
branch and have all pulls and pushes only go to that branch.



 What I’m saying is that a lot of Bazaar terminology using “branch” does
 not map as-is to Mercurial.  We clone a repo, we pull from a repo/clone,
 we have named branches (e.g. 3.2) in a repo, we have unnamed branches on
 one named branch.  I think you know that already, since you went from
 using Bazaar terms applied to Mercurial to mixing terms from both
 (“clone a new branch working directory” → “clone a repo”, probably).  I
 salute your willingness to learn Mercurial, considering how fluent (and
 fluffly) you appear to be with Bazaar.

 This is an inevitable problem with trying to converse fluently about three
 major dVCSs and at least one or two other non-dVCSs.  

Re: [Python-Dev] Mercurial conversion repositories

[Barry Warsaw]

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 with two files, one is the commit message and the other is the diff.
(The script itself is a bit buggy too. ;)

But it's a good clue, and I've modified the default hgeditor script to get
closer, and fix the bug I noticed.  I basically append the diff to the
temporary log message file.  It's still not right though because if the diff
lines aren't prepended with 'HG:', they end up in the commit message.  Arg.

Oh well, I can clearly hack a more complicated script together.  It's such a
blindingly obvious improvement, it's too bad 'hg commit' doesn't DTRT by
default.

-Barry


signature.asc
Description: PGP signature
___
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 conversion repositories

[Tim Delaney]

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 default.
 
  Problem is, you then have 1.5.2 released from the 2.x branch :)

 In that case, legacy-trunk would seem clearer.


+1

Exactly what I was about to suggest.

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 conversion repositories

[Barry Warsaw]

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
 Mercurial remembered the pull URL for me, as (you guessed it :) Bazaar does.

How does setting it in the hgrc differ from remebering it?

It's different because you don't use a familiar interface to set it (i.e hg).
You have to know to hack a file to make it work.  That's not awesome user
interface. ;)

I've never been comfortable with the bzr --remember option because I'm never
sure what it is remembering.  Much easier for me to see it in a config file.
But, then, that's how my brain works, and other people's will work
differently.

It's easy to tell what it remembers because it's exactly what you told it to
remember ;).  But I guess you're talking about push and pull automatically
remembering the location when none was previously set.  I love that feature.

And of course, bzr 'remembers' by setting a value in a config file, which of
course you *could* hack if you wanted to.  It's just that you don't normally
have to open your editor and remember which value in which config file you
have to manually modify to set the push and pull locations.  I think that's a
win, but YMMV. :)

Oh, and 'bzr info' always tells you what the push and pull locations are.

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 working copy, and that the repository is *the*
repository.  That is, it has everything related to the project in it,
just like the master SVN repository does (plus, since it is a DVCS,
whatever I've committed locally but not pushed to the master).  To have
a repository that only has some of the stuff in it is, IMO, confusing.
I advocated for having all the Python history in one repo partly for
that reason.

I would feel better about Mercurial's if the repo where not intimately tied
with a default working tree (yes, I know -U).  In a sense, that's what
Bazaar's shared repositories are: a place where all your history goes.  In
Bazaar's model though, it's not tied to a specific working tree, and it's
hidden in a dot-directory.

It's still kind of beside the point - this is the way Mercurial works, and I
don't really mean this thread to be an in-depth comparison between the two.

-Barry


signature.asc
Description: PGP signature
___
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 conversion repositories

[Antoine Pitrou]

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 a working copy, and that the repository is *the*
 repository.  That is, it has everything related to the project in it,
 just like the master SVN repository does (plus, since it is a DVCS,
 whatever I've committed locally but not pushed to the master).  To have
 a repository that only has some of the stuff in it is, IMO, confusing.
 I advocated for having all the Python history in one repo partly for
 that reason.
 
 I would feel better about Mercurial's if the repo where not intimately tied
 with a default working tree (yes, I know -U).  In a sense, that's what
 Bazaar's shared repositories are: a place where all your history goes.  In
 Bazaar's model though, it's not tied to a specific working tree, and it's
 hidden in a dot-directory.

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

Regards

Antoine.


___
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 conversion repositories

[Barry Warsaw]

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
 have
 a 'cpython' directory containing the history of all LoDs, but with a
 working
 directory that reflects the 'default' LoD.  Now, in the parent of
 'cpython', I
 do the following to get my separate-directory-LoDs:

 $ hg clone -u 2.6 cpython py26
 $ hg clone -u 2.7 cpython py27
 # repeat and rinse for all other active LoDs


That's one way of doing it.

I'm sure there are many different ways of setting things up.  I am totally in
favor of the devguide documenting and encouraging one particular way, and I'm
sure Mercurial will prove to be a flexible tool that can conform to user's
preferences rather than the other way 'round.

 (Aside: that cpython directory still bugs me.  It doesn't naturally reflect
 a
 LoD, so why do I have to stare at it?  Yes, I can make it play double duty
 by
 naming it 3.3 or whatever and updating it to the 3.3 LoD, but that feels
 artificial.)

It's a clone repository of CPython; the name makes perfect sense. You are
focusing on what the repository happens to be updated to ATM, not the fact
that the repository itself represents any and all LoDs.

No, I get all that.  I'm just not sure why I should care where all the history
is stored.  I'm not actually going to do any coding in the cpython directory,
so it just seems like a wart I have to carry around.  But as I said before,
this is the Mercurial Way, so be it.

 Now I want to synchronize my local py27 directory with the state of that
 LoD
 on python.org.  This is a two step process:

 $ cd py27 # now I want to synchronize
 $ (cd ../cpython  hg pull)
 $ hg pull -u

 Editing hgrc to point to hg.python.org means the sync-to-remote-master
 operation is one command.

 I could do this:

 $ 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
 does.


So does Hg: simply edit your .hgrc to have it both pull and push to the same
URL.

Right, see my follow up to RDM.

Or you can save yourself some trouble, and simply clone the repository at a
specific branch:

  hg clone ssh://h...@hg.python.org/cpython#2.7

I believe that might even strip out other history outside the scope of the
branch.

That might be a better way if it doesn't slurp down the entire repository
history.

 Anecdote: I migrated from Subversion to Mercurial a few years ago, and
 found Mercurial branches very intuitive.  When I saw mentions of Bazaar
 branches I was driven nuts by (what I saw as) the conflation between a
 branch and a clone.  Later I understood how it made sense from the
 perspective of Bazaar, so I shifted my judgment from “insanely
 confusing” to “a particular choice that I don’t approve” wink.

 That's funny because to my eyes, Mercurial conflates branches and
 clones.
 Why a clone operation should give me the history for all
 lines-of-development
 inside a working directory for one arbitrary one strikes me as bizarre
 (pardon the pun :).

Because Hg views a clone as that: a clone of the entire repository. A branch
just happens to be a part of the repository. And because it is the entire
repository it has to have you point somewhere, so it goes with default since
a lot of people never even work somewhere other than on default.

Yep, I get all that.  It's Mercurial's model of the world.

Yes, fun isn't it? Makes me that much more glad I don't have to care about
other DVCSs anymore; make the decision of which one to go through was
painful partially for this reason.

Lucky you!  I interact with tons of projects, so I still have to deal with
everything from CVS to git.  This will be my first serious foray into hg, and
for that I'm glad.  And really, *any* dVCS is better than a non-dVCS, so I'm
really happy this is finally happening, despite any initial grumbling you're
reading into my posts. :)

  I'll have to remember that 'hg pull' does not update the working copy by
  default,
 
 That pull does not update is a feature: The operation between a remote
 repo and the local repo (the .hg directory) is separate from the
 operation from the local repo to the working directory.  When you know
 that you want pull + update (like when you have a clean working
 directory), you use “hg pull -u”.  (I don’t like the fetch command.)

 Sure, I get that.  Again, this feature appears odd because I have the full
 history of all LoDs embedded in a working directory of a single LoD.

Not single, _current_. I know you don't like the whole svn switch approach
that this is like, but Hg is very much about don't forget a thing, which
is why you need to view a clone as a clone repository that you are choosing

Re: [Python-Dev] Mercurial conversion repositories

[Barry Warsaw]

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


signature.asc
Description: PGP signature
___
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 conversion repositories

[Brett Cannon]

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 clone the remote repository using the command in the devguide, so I
 now
  have
  a 'cpython' directory containing the history of all LoDs, but with a
  working
  directory that reflects the 'default' LoD.  Now, in the parent of
  'cpython', I
  do the following to get my separate-directory-LoDs:
 
  $ hg clone -u 2.6 cpython py26
  $ hg clone -u 2.7 cpython py27
  # repeat and rinse for all other active LoDs
 
 
 That's one way of doing it.

 I'm sure there are many different ways of setting things up.  I am totally
 in
 favor of the devguide documenting and encouraging one particular way, and
 I'm
 sure Mercurial will prove to be a flexible tool that can conform to user's
 preferences rather than the other way 'round.

  (Aside: that cpython directory still bugs me.  It doesn't naturally
 reflect
  a
  LoD, so why do I have to stare at it?  Yes, I can make it play double
 duty
  by
  naming it 3.3 or whatever and updating it to the 3.3 LoD, but that
 feels
  artificial.)
 
 It's a clone repository of CPython; the name makes perfect sense. You are
 focusing on what the repository happens to be updated to ATM, not the fact
 that the repository itself represents any and all LoDs.

 No, I get all that.  I'm just not sure why I should care where all the
 history
 is stored.  I'm not actually going to do any coding in the cpython
 directory,
 so it just seems like a wart I have to carry around.  But as I said before,
 this is the Mercurial Way, so be it.

  Now I want to synchronize my local py27 directory with the state of that
  LoD
  on python.org.  This is a two step process:
 
  $ cd py27 # now I want to synchronize
  $ (cd ../cpython  hg pull)
  $ hg pull -u
 
  Editing hgrc to point to hg.python.org means the sync-to-remote-master
  operation is one command.
 
  I could do this:
 
  $ 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
  does.
 
 
 So does Hg: simply edit your .hgrc to have it both pull and push to the
 same
 URL.

 Right, see my follow up to RDM.

 Or you can save yourself some trouble, and simply clone the repository at
 a
 specific branch:
 
   hg clone ssh://h...@hg.python.org/cpython#2.7
 
 I believe that might even strip out other history outside the scope of the
 branch.

 That might be a better way if it doesn't slurp down the entire repository
 history.

  Anecdote: I migrated from Subversion to Mercurial a few years ago, and
  found Mercurial branches very intuitive.  When I saw mentions of Bazaar
  branches I was driven nuts by (what I saw as) the conflation between a
  branch and a clone.  Later I understood how it made sense from the
  perspective of Bazaar, so I shifted my judgment from “insanely
  confusing” to “a particular choice that I don’t approve” wink.
 
  That's funny because to my eyes, Mercurial conflates branches and
  clones.
  Why a clone operation should give me the history for all
  lines-of-development
  inside a working directory for one arbitrary one strikes me as bizarre
  (pardon the pun :).
 
 Because Hg views a clone as that: a clone of the entire repository. A
 branch
 just happens to be a part of the repository. And because it is the entire
 repository it has to have you point somewhere, so it goes with default
 since
 a lot of people never even work somewhere other than on default.

 Yep, I get all that.  It's Mercurial's model of the world.

 Yes, fun isn't it? Makes me that much more glad I don't have to care about
 other DVCSs anymore; make the decision of which one to go through was
 painful partially for this reason.

 Lucky you!  I interact with tons of projects, so I still have to deal with
 everything from CVS to git.  This will be my first serious foray into hg,
 and
 for that I'm glad.  And really, *any* dVCS is better than a non-dVCS, so
 I'm
 really happy this is finally happening, despite any initial grumbling
 you're
 reading into my posts. :)

   I'll have to remember that 'hg pull' does not update the working copy
 by
   default,
  
  That pull does not update is a feature: The operation between a remote
  repo and the local repo (the .hg directory) is separate from the
  operation from the local repo to the working directory.  When you know
  that you want pull + update (like when you have a clean working
  directory), you use “hg pull -u”.  (I don’t like the fetch command.)
 
  Sure, I get that.  Again, this feature appears odd because I have the
 full
  history of all LoDs embedded in a working directory of a single LoD.
 
 Not single, _current_. I 

Re: [Python-Dev] Mercurial conversion repositories

[Dj Gilcrease]

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 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 conversion repositories

[Adrian Buehlmann]

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 every time.  It wouldn't be so bad if
 Mercurial remembered the pull URL for me, as (you guessed it :) Bazaar does.

 How does setting it in the hgrc differ from remebering it?
 
 It's different because you don't use a familiar interface to set it (i.e hg).
 You have to know to hack a file to make it work.  That's not awesome user
 interface. ;)

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.

And he's quite firm on not wanting to have Mercurial touch .hg/hgrc --
with the single exception being to write a initial .hg/hgrc on 'hg
clone', containing the default path with the location from where the
repo was cloned.

Regarding Bazaar: FWIW, I periodically retried the speed of 'bzr check'
- and always gave up again looking at bzr due to the horrible slowness
of that command. If I have to use a DVCS I want to be able to check the
integrity of my clones in reasonable time. I do it with a cron job on
our internal server here and I expect it to have finished checking all
our repos when I get to my desk in the morning and look into my email
inbox, reading the daily email with the result of the verify runs.

After all, we do have everything secured with hashes, so we can use
them, don't we?

 I've never been comfortable with the bzr --remember option because I'm never
 sure what it is remembering.  Much easier for me to see it in a config file.
 But, then, that's how my brain works, and other people's will work
 differently.
 
 It's easy to tell what it remembers because it's exactly what you told it to
 remember ;).  But I guess you're talking about push and pull automatically
 remembering the location when none was previously set.  I love that feature.
 
 And of course, bzr 'remembers' by setting a value in a config file, which of
 course you *could* hack if you wanted to.  It's just that you don't normally
 have to open your editor and remember which value in which config file you
 have to manually modify to set the push and pull locations.  I think that's a
 win, but YMMV. :)
 
 Oh, and 'bzr info' always tells you what the push and pull locations are.

You can use 'hg paths' for that:

See http://selenic.com/repo/hg/help/paths or 'hg help paths' on the
command line.

 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 working copy, and that the repository is *the*
 repository.  That is, it has everything related to the project in it,
 just like the master SVN repository does (plus, since it is a DVCS,
 whatever I've committed locally but not pushed to the master).  To have
 a repository that only has some of the stuff in it is, IMO, confusing.
 I advocated for having all the Python history in one repo partly for
 that reason.
 
 I would feel better about Mercurial's if the repo where not intimately tied
 with a default working tree (yes, I know -U).  In a sense, that's what
 Bazaar's shared repositories are: a place where all your history goes.  In
 Bazaar's model though, it's not tied to a specific working tree, and it's
 hidden in a dot-directory.
 
 It's still kind of beside the point - this is the way Mercurial works, and I
 don't really mean this thread to be an in-depth comparison between the two.

I'm quite surprised indeed to read that much about Bazaar in this thread
here :)
___
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 conversion repositories

[Daniel Stutzbach]

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 matter of perspective.

I spent some time on Friday setting up hg-git on my workstation and making a
few test commits.  It took me awhile to figure out how to get everything
working, but it seems to work smoothly now.  At some point I'll update
http://wiki.python.org/moin/Git with instructions.

-- 
Daniel Stutzbach
___
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 conversion repositories

[Barry Warsaw]

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 speed of 'bzr check'
- and always gave up again looking at bzr due to the horrible slowness
of that command. If I have to use a DVCS I want to be able to check the
integrity of my clones in reasonable time. I do it with a cron job on
our internal server here and I expect it to have finished checking all
our repos when I get to my desk in the morning and look into my email
inbox, reading the daily email with the result of the verify runs.

After all, we do have everything secured with hashes, so we can use
them, don't we?

Do you know how thorough 'bzr check' is?  I don't, but then I've never used it
or felt the need to. ;)

 Oh, and 'bzr info' always tells you what the push and pull locations are.

You can use 'hg paths' for that:

Nice, thanks.

-Barry


signature.asc
Description: PGP signature
___
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 conversion repositories

[Adrian Buehlmann]

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. :)

Yep.

 Regarding Bazaar: FWIW, I periodically retried the speed of 'bzr check'
 - and always gave up again looking at bzr due to the horrible slowness
 of that command. If I have to use a DVCS I want to be able to check the
 integrity of my clones in reasonable time. I do it with a cron job on
 our internal server here and I expect it to have finished checking all
 our repos when I get to my desk in the morning and look into my email
 inbox, reading the daily email with the result of the verify runs.

 After all, we do have everything secured with hashes, so we can use
 them, don't we?
 
 Do you know how thorough 'bzr check' is?  I don't, but then I've never used it
 or felt the need to. ;)

That's quite amazing. If I talk with people about that, it often turns
out that they don't check the integrity of their repos.

Well, hg verify *is* through and fast enough. That's good enough for me.

And being slow is not sufficient to earn my trust.

FWIW, be aware that Mercurial does not do integrity checks on normal
operations, so chances are you will be able to use a repo that fails
verify for quite a while -- without even noticing it.

For example you can remove *some* file X inside .hg/store/data and
continue to add history to that repo without any sign of errors, as long
as the file X isn't used during the operations you do.
___
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 conversion repositories

[Martin v. Löwis]

 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 similar
 output).

It's probably a terminology issue, but: the changeset can't be on
the default branch, because the head of the default branch (called
tip, IIUC) isn't a descendant of that changeset. It's parent is

changeset:   72693:d9769c8a828b
user:Antoine Pitrou solip...@pitrou.net
date:Mon Feb 21 21:25:39 2011 +
summary: temp branch to debug crashes on snow leopard buildbot

so you have called it temporary branch in subversion. I got go with
that term also, if unnamed branch is confusing.

 I think we can do better. I also dislike hg log --only-branch default
 to only go back to 2006 (to aeefba456e4d), when this revision actually
 does have a parent (namely, on the trunk branch, 4b41806a0326).
 
 I'm not convinced that small quirks of using hg log are important at
 this point. Also, you could try other options of hg log such as
 --follow.

IIUC, --follow doesn't help. It traces history across renames and
copies, which is not what I want to overcome when trying to produce the
full history of the py3k branch.

As for small quirks ... important at this point: this point is the
*only* chance to get it right. If you get it wrong now, we will have
to deal with it forever (or rather until we switch to the next
version control system).

If you chose to convert in the way it currently does:
fine with me, as long as the choice was deliberate (rather than
coincidental).

 If we called ex-trunk the same name as ex-py3k (default), things would
 probably be quite more confusing, since inspecting a changeset wouldn't
 tell you immediately where it comes from (2.x or 3.x development).

I would it call default only up to the point where the py3k branch was
branched off trunk. All changes up to this point actually *do* belong
to both branches. Python 3's history goes all the way back to 0.9,
and I'm sure you can still find code in 3.2 which was written 20 years
ago.

Change sets created after 3.x was forked off should certainly live
on a separate mercurial branch - it would be reasonable to call this
branch then 2.x.

Regards,
Martin
___
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 conversion repositories

[Martin v. Löwis]

 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 is not mentioned
- the branchmap is (apparently?) not evaluated; in particular,
  it's not clear whether the keep-clone branches went.
- it's not clear what your view on the subversion repository
  is - do you keep the notion of discarded branches (i.e. branches
  that can only be discovered from looking at a copy of the subversion
  repository), or do you mean to convert everything?

As for the cpythonextrahist repository: why are the heads all unnamed?
How are you supposed to find anything in it?

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).

Regards,
Martin
___
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 conversion repositories

[Neil Hodgson]

   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 produces a large
amount of output with almost all the *.decTest and most of the Windows
build files (*.mk, *.sln, *.vcproj, *.bat) showing as changed but with
identical text.

   I've had problems like this with Hg before
(http://mercurial.selenic.com/bts/issue2287). The situation can be
fixed by hg update to another version and then back to default.

   Neil
___
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 conversion repositories

[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 trivial to convert to clones.

Cheers,

Dirkjan
___
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 conversion repositories

[Martin v. Löwis]

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 trivial to convert to clones.

If there are hundreds of them, it's far from trivial. I don't even know
how to find out which one to convert.

Regards,
Martin
___
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 conversion repositories

[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 extract into
a clone (at least that's how I was planning to do it, not sure what
their idea is).

Cheers,

Dirkjan
___
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 conversion repositories

[Martin v. Löwis]

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 extract into
 a clone (at least that's how I was planning to do it, not sure what
 their idea is).

Ah ok. So I guess that goes back to my original request - that the PEP
be updated.

Regards,
Martin
___
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 conversion repositories

[Raymond Hettinger]

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 separate, it would complicate backporting patches
and merges.  So, I'm happy with how George and Benjamin put this together.

Raymond

___
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 conversion repositories

[Antoine Pitrou]

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 in the
repository right now (it's in the SVN repository too), but it doesn't
match the reality of on-disk files, so when you update, the eol
extension tries to fix those files.

Regards

Antoine.
___
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 conversion repositories

[Antoine Pitrou]

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
 3.167955:5be8b695ea86
 2.667287:5e26a860eded
 2.565464:e4ecac76e499
 trunk  62750:800f6c92c3ed
 3.060075:1d05144224fe
 2.458552:df72cac1899e
 2.345731:a3d9a9730743
 2.240444:d55ddc8c8501
 2.130171:06fcccf6eca8
 2.018214:dc0dfc9565cd
 
  The branch default is the current py3k branch from SVN. The branch
  trunk represents SVN trunk history until 2.7 was branched for
  maintenance.
 
 
 Just to help justify it in my head, the trunk branch exists for the history
 and nothing more, right?

True.

 Could we actually close the branch so it isn't even visible by default
 to prevent confusing people?

Yes, we can. This can be done post-conversion, actually. Something like:

$ hg up trunk
$ hg ci --close-branch -m Close trunk

Regards

Antoine.
___
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 conversion repositories

[Georg Brandl]

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 single repository).
 
 Unnamed heads are trivial to convert to clones.
 
 If there are hundreds of them, it's far from trivial. I don't even know
 how to find out which one to convert.

The full-history repo has several ways to get at that information, so it's
quite for us to extract feature branches as separate clones.

Since most side-track branches won't actually be needed anymore, we'd like
to reconstruct them on request.  I assume you'd like to have pep-0383?

Georg

___
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 conversion repositories

[Barry Warsaw]

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 repository has been easy to work with.
If they were separate, it would complicate backporting patches
and merges.  So, I'm happy with how George and Benjamin put this together.

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
~/projects/python/py3k

This makes it very easy to just cd, svn up, make distclean, configure, make to
test things.  How can I do this with the hg clone when all the branches are
in the single repository, but more or less hidden?  After doing the 'hg clone'
operation specified by Antoine, I'm left with a single cpython directory
containing (iiuc) the contents of the 'default' branch.

I'm sure I'm not the only one who works this way with Subversion.  IWBN to
cover this in the devguide (or is it there and I missed it?).

Cheers,
-Barry


signature.asc
Description: PGP signature
___
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 conversion repositories

[Antoine Pitrou]

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
 ~/projects/python/py3k
 
 This makes it very easy to just cd, svn up, make distclean, configure, make to
 test things.  How can I do this with the hg clone when all the branches are
 in the single repository, but more or less hidden?  After doing the 'hg clone'
 operation specified by Antoine, I'm left with a single cpython directory
 containing (iiuc) the contents of the 'default' branch.

Indeed, the default branch is checked out by default. But you can
switch to another branch:

$ hg sum
parent: 68026:f12ef116dd10 tip
 In FTP.close() method, make sure to also close the socket object, not only the 
file.
branch: default
commit: (clean)
update: (current)

$ hg up 2.7
3310 files updated, 0 files merged, 378 files removed, 0 files unresolved

$ hg sum
parent: 68010:8174d00d0797 
 Merged revisions 88486 via svnmerge from
branch: 2.7
commit: (clean)
update: (current)

(hg sum is a shorthand for hg summary)

Furthermore, once you have a local clone, you can clone it further to
get several independent clones, and keep each of them updated on
whatever branch you want. This makes it easy to replicate your workflow
(by having a master clone - a mirror if you want - and then child
clones that get updated from the master clone by running hg pull).

 I'm sure I'm not the only one who works this way with Subversion.  IWBN to
 cover this in the devguide (or is it there and I missed it?).

Use of hg update to switch between branches is mentioned in 
http://potrou.net/hgdevguide/setup.html#getting-the-source-code
and also http://potrou.net/hgdevguide/coredev.html#read-write-checkout
and also in
http://potrou.net/hgdevguide/committing.html#porting-within-a-major-version.

But a dedicated FAQ entry could be added.

Regards

Antoine.


___
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 conversion repositories

[Georg Brandl]

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 repository).

In my brief tests, the single repository has been easy to work with.
If they were separate, it would complicate backporting patches
and merges.  So, I'm happy with how George and Benjamin put this together.
 
 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
 ~/projects/python/py3k
 
 This makes it very easy to just cd, svn up, make distclean, configure, make to
 test things.  How can I do this with the hg clone when all the branches are
 in the single repository, but more or less hidden?  After doing the 'hg clone'
 operation specified by Antoine, I'm left with a single cpython directory
 containing (iiuc) the contents of the 'default' branch.

Two scenarios are possible:

* You make a clone per branch with the full history, with the current branch
  being different in each of those.  Since hg update updates to the head of
  the current branch, this should be easy to do.  When you pull from the single
  repo you will get changes for the other branches as well, but they will not
  bother you.

* You make a clone per branch, containing *only* the respective branch (with
  its ancestors).  This is done by using URI#branchname as the source when
  cloning/pulling.

Both should work equally well, with the former giving larger repository sizes,
and the latter taking somewhat longer on the initial clone.

Georg

___
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 conversion repositories

[Georg Brandl]

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, rather than putting all
 in a single repository).

In my brief tests, the single repository has been easy to work with.
If they were separate, it would complicate backporting patches
and merges.  So, I'm happy with how George and Benjamin put this together.
 
 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
 ~/projects/python/py3k
 
 This makes it very easy to just cd, svn up, make distclean, configure, make 
 to
 test things.  How can I do this with the hg clone when all the branches are
 in the single repository, but more or less hidden?  After doing the 'hg 
 clone'
 operation specified by Antoine, I'm left with a single cpython directory
 containing (iiuc) the contents of the 'default' branch.
 
 Two scenarios are possible:
 
 * You make a clone per branch with the full history, with the current branch
   being different in each of those.  Since hg update updates to the head of
   the current branch, this should be easy to do.  When you pull from the 
 single
   repo you will get changes for the other branches as well, but they will not
   bother you.
 
 * You make a clone per branch, containing *only* the respective branch (with
   its ancestors).  This is done by using URI#branchname as the source when
   cloning/pulling.
 
 Both should work equally well, with the former giving larger repository sizes,
 and the latter taking somewhat longer on the initial clone.

Ah, and the latter obviously also won't work with the hg-native workflow
(merging between the branches using hg merge).

Georg

___
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 conversion repositories

[Antoine Pitrou]

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 enabled in global settings.
 
 Yes, please try to disable it. The issue is we have a .hgeol in the
 repository right now (it's in the SVN repository too), but it doesn't
 match the reality of on-disk files, so when you update, the eol
 extension tries to fix those files.

It should now be fixed in current SVN, meaning the final conversion
should be perfectly usable with the eol extension enabled.

Do you find other issues under Windows? Have you tried pushing changes?

Regards

Antoine.


___
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 conversion repositories

[Adrian Buehlmann]

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 repository).

 In my brief tests, the single repository has been easy to work with.
 If they were separate, it would complicate backporting patches
 and merges.  So, I'm happy with how George and Benjamin put this together.
 
 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
 ~/projects/python/py3k
 
 This makes it very easy to just cd, svn up, make distclean, configure, make to
 test things.  How can I do this with the hg clone when all the branches are
 in the single repository, but more or less hidden?  After doing the 'hg clone'
 operation specified by Antoine, I'm left with a single cpython directory
 containing (iiuc) the contents of the 'default' branch.
 
 I'm sure I'm not the only one who works this way with Subversion.  IWBN to
 cover this in the devguide (or is it there and I missed it?).

I know (almost) nothing about developing Python (this is my first post
to this list after lurking for quite a while now), but as a regular
Mercurial contributor, I think the following could be useful for you:

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 option -u:

  $ hg clone master py26 -u 2.6
  updating to branch 2.6
  NNN files updated, 0 files merged, 0 files removed, 0 files unresolved

  $ hg clone master py27 -u 2.7
  updating to branch 2.7
  NNN files updated, 0 files merged, 0 files removed, 0 files unresolved

  $ hg clone master trunk -u trunk
  updating to branch trunk
  NNN files updated, 0 files merged, 0 files removed, 0 files unresolved

  $ hg clone master py31 -u 3.1
  updating to branch 3.1
  NNN files updated, 0 files merged, 0 files removed, 0 files unresolved

  $ hg clone master py32 -u 3.2
  updating to branch 3.2
  NNN files updated, 0 files merged, 0 files removed, 0 files unresolved

This will be fast and save space as these local 'branch clones' will
share diskspace inside .hg/store by using hardlinks, and you need to do
the initial slow clone over the wire only once.

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...@hg.python.org/cpython instead, you'd
want to edit the [paths] section in the .hg/hgrc file in each of the
branch repos. But of course you can also leave the default paths as they
are and synchronize via the master repo (e.g. pull new changesets into
master first, and then pull into the specific branch repo).

[1] http://selenic.com/repo/hg/help/clone
[2] http://mercurial.selenic.com/wiki/HardlinkedClones
[3] http://www.selenic.com/mercurial/hgrc.5.html#paths
[4] http://selenic.com/repo/hg/help/urls
___
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 conversion repositories

[Barry Warsaw]

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 option -u:

  $ hg clone master py26 -u 2.6
  updating to branch 2.6
  NNN files updated, 0 files merged, 0 files removed, 0 files unresolved

  $ hg clone master py27 -u 2.7
  updating to branch 2.7
  NNN files updated, 0 files merged, 0 files removed, 0 files unresolved

  $ hg clone master trunk -u trunk
  updating to branch trunk
  NNN files updated, 0 files merged, 0 files removed, 0 files unresolved

  $ hg clone master py31 -u 3.1
  updating to branch 3.1
  NNN files updated, 0 files merged, 0 files removed, 0 files unresolved

  $ hg clone master py32 -u 3.2
  updating to branch 3.2
  NNN files updated, 0 files merged, 0 files removed, 0 files unresolved

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...@hg.python.org/cpython instead, you'd
want to edit the [paths] section in the .hg/hgrc file in each of the
branch repos.

Thanks very much Adrian, this is exactly what I was looking for.  It maps
almost directly to my current mental model for working on Python in Subversion
(and truth be told, also how I do/did it with Bazaar).

It does leave me with an empty 'master' directory that I basically won't
touch, though I suppose I could hide it in a dot-filename.  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.

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.

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, and I always have all the information I want right there to
craft the commit message.  It doesn't look like this is possible with 'hg
commit' though, right?

Cheers,
-Barry


signature.asc
Description: PGP signature
___
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