Re: [Python-Dev] Mercurial conversion repositories
Barry Warsaw writes: > You mean, TortoiseHg supports incremental commits on a single file? That's > kind of neat, but scary. ;) Darcs people have been doing this for, well, for as long as Darcs has existed. It's not scary at all. In fact, in Darcs you can select hunks across files, too. ___ 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] devguide (hg_transition): Advertise hg import over patch.
On 2011-02-27 23:21, Neil Hodgson wrote: > Adrian Buehlmann: > >> FWIW, we are very close to releasing TortoiseHg 2.0 (due March 1st), >> which ported the current Gtk based TortoiseHg to Qt (although, it was >> more like a rewrite :-). > >I hope this is going to be fast. Here, the Workbench window [1] starts in under 2s (Windows 7 x64 on Intel Core2 Quad). As installed with the x64 msi (installs true 64 bit exe's, including 64 bit command line hg). There's quite a lot of demand loading behind the scenes. So it's fast even for repos with many changesets. [1] http://tortoisehg.bitbucket.org/manual/2.0/workbench.html (brand new first manual version by Steve was just uploaded a few minutes ago :) ___ 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] devguide (hg_transition): Advertise hg import over patch.
Adrian Buehlmann: > FWIW, we are very close to releasing TortoiseHg 2.0 (due March 1st), > which ported the current Gtk based TortoiseHg to Qt (although, it was > more like a rewrite :-). I hope this is going to be fast. One of the reasons I chose Hg over Bzr for another project was that the Bzr GUI tools which are written using Qt are much slower, particularly when starting. A cold start of Bazaar Explorer takes around 7 seconds on a new fast machine compared with under a second to launch Hg Repository Explorer. Warm starts and internal actions are better but the Hg GUI tools are still much smoother than Bzr's. This slowness is quite common for Qt applications and I think is because of the large set of DLLs that are loaded. Qt Creator is better at around 4 seconds for a cold launch but, naturally, it doesn't matter for an environment which you use for an extended period like Qt Creator. It does matter for a VCS tool that you may invoke hundreds of times in a day. 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] devguide (hg_transition): Advertise hg import over patch.
Scott Dial: > I don't believe TortoiseHG has such a feature (or I can't find it), > although if you have TortoiseSVN, you can still use that as a patch tool. The Import... command is in the Synchronize menu of Hg Repository Explorer. There is no GUI equivalent to --no-commit but you can exit the commit message editor without saving which causes the commit to be abandoned with the patch still having been applied. 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] Let's get PEP 380 into Python 3.3
Guido van Rossum wrote: Ok. Will you hvae time to port your patches to 3.3? I'm not sure -- I'll see what I can do. -- Greg ___ 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] hg extensions was Mercurial conversion repositories
>> My assumption was that most developers don't use MSVC, so most of them >> don't risk breaking eols ;) >> True, for Windows devs it might be necessary to promote it. > > Windows devs were the original target audience, yes :) I meant to say that earlier: thanks to everybody involved in the original development of the eol extension. It originated from python-dev, and, with the switchover taking so long as it took, it's a standard extension of Mercurial releases by now. In the Tortoise Global Settings GUI, there is even a checkbox to activate it. 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] hg extensions was Mercurial conversion repositories
>> I think this is overly optimistic. Visual Studio will break all your >> files if you don't use that extension (and you actually use it to >> modify source code). > > My assumption was that most developers don't use MSVC, so most of them > don't risk breaking eols ;) > True, for Windows devs it might be necessary to promote it. If I change code on Windows, I always use MSVC to edit it. It's best integrated with the build process and the debugger. If I change Python code on Windows, I use vim or IDLE. Different MSVC releases took different approaches wrt. LF-separated files. For a long time, new lines added would be CRLF, whereas existing line endings would remain unchanged, resulting in a mix of line endings. It appears that VS 2008 now uniformly converts the entire file to CRLF on first edit. 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
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] devguide (hg_transition): Minor edits and typo fixes.
Le 27/02/2011 16:22, Antoine Pitrou a écrit : >> - Remove one XXX that was in a warning block, not a comment > Well, this is a XXX because that means we could find something else to > advocate, not because the reader must take it as a warning. My point was that that should be either a comment with an XXX marker or a user-visible reST warning. I chose the latter, I have no problem changing it to the former. 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] devguide (hg_transition): patchcheck does work
Le 27/02/2011 16:21, Antoine Pitrou a écrit : >> summary: >> patchcheck does work > How does it find out which changesets it should operate on? It operates on changed files, just like with Subversion: http://hg.python.org/cpython/file/tip/Tools/scripts/patchcheck.py#l40 → hg status --added --modified --no-status You can use it while making a commit, or when you collapse many commits into one diff (and apply it with hg import --no-commit). Rewriting patchcheck to work on diffs is another thing, see http://bugs.python.org/issue8999#msg109255 I agree that the part about patchcheck should have a note to explain that it works with uncommitted changes, not MQ patches or changesets. 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] devguide (hg_transition): Advertise hg import over patch.
On 2011-02-27 16:35, Scott Dial wrote: > On 2/27/2011 10:18 AM, Antoine Pitrou wrote: >> Well, chances are TortoiseHG comes with an UI to apply patches >> (TortoiseSVN had one), so the command-line instructions may be of >> little use to them. > > I don't believe TortoiseHG has such a feature (or I can't find it), > although if you have TortoiseSVN, you can still use that as a patch tool. TortoiseHg can import patches just fine. FWIW, we are very close to releasing TortoiseHg 2.0 (due March 1st), which ported the current Gtk based TortoiseHg to Qt (although, it was more like a rewrite :-). For the old Gtk TortoiseHg, see the online docs here: http://tortoisehg.bitbucket.org/manual/1.1/patches.html#import-patches Homepage for the Qt port: https://bitbucket.org/tortoisehg/thg/wiki/Home For people on Windows, we have beta installers for the new Qt based TortoiseHg at: https://bitbucket.org/tortoisehg/thg/downloads Feedback is welcome on thg-...@googlegroups.com or tortoisehg-disc...@lists.sourceforge.net (we moved the development list to google groups) ___ 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] devguide (hg_transition): Advertise hg import over patch.
On 2/27/2011 10:18 AM, Antoine Pitrou wrote: > Well, chances are TortoiseHG comes with an UI to apply patches > (TortoiseSVN had one), so the command-line instructions may be of > little use to them. I don't believe TortoiseHG has such a feature (or I can't find it), although if you have TortoiseSVN, you can still use that as a patch tool. -- Scott Dial sc...@scottdial.com scod...@cs.indiana.edu ___ 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] devguide (hg_transition): Minor edits and typo fixes.
On Sun, 27 Feb 2011 04:17:09 +0100 eric.araujo wrote: > > - Move a link target after its use > - Add a todo about tracker markup > - Remove one XXX that was in a warning block, not a comment Well, this is a XXX because that means we could find something else to advocate, not because the reader must take it as a warning. ___ 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] [Python-checkins] hooks: Fix checkbranch hook
On Sat, Feb 26, 2011 at 11:48 PM, Nick Coghlan wrote: > On Sun, Feb 27, 2011 at 5:26 PM, "Martin v. Löwis" > wrote: > > If you think that it's a likely problem that people create named > > branches by mistake, then we should have a hook. > > I suspect the concern is that people may create named branches locally > as part of their own workflow, then mistakenly push those branches > instead of collapsing back to a single commit against the relevant > line of development. > +1 -- 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] devguide (hg_transition): patchcheck does work
On Sun, 27 Feb 2011 04:17:07 +0100 eric.araujo wrote: > summary: > patchcheck does work How does it find out which changesets it should operate on? ___ 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] hg extensions was Mercurial conversion repositories
On Mon, Feb 28, 2011 at 1:12 AM, Antoine Pitrou wrote: > On Sun, 27 Feb 2011 07:46:51 +0100 > "Martin v. Löwis" wrote: >> > Actually, it isn't *required* on each developer's setup, since we >> > now have a hook that refuses bogus changegroups (if needed, we can even >> > refuse individual changesets). In most situations, even without the >> > eol extension line endings won't get modified anyway. >> >> I think this is overly optimistic. Visual Studio will break all your >> files if you don't use that extension (and you actually use it to >> modify source code). > > My assumption was that most developers don't use MSVC, so most of them > don't risk breaking eols ;) > True, for Windows devs it might be necessary to promote it. Windows devs were the original target audience, yes :) 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] of branches and heads
On Sun, Feb 27, 2011 at 2:42 AM, Adrian Buehlmann wrote: > On 2011-02-26 23:26, Greg Ewing wrote: > > There are *some* topological restrictions, because hg won't > > let you assign a branch name that's been used before to a node > > unless one of its parents has that name. So you can't create > > two disconnected subgraphs whose nodes have the same branch > > name. > > That's not completely correct. You *can* do that. > Can we create a hook on the server to reject changesets like that? -- 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] devguide (hg_transition): Advertise hg import over patch.
On Sun, 27 Feb 2011 04:17:06 +0100 eric.araujo wrote: > Advertise hg import over patch. > > hg import understands the extended git diff format, which supports renames, > changes to the executable bit and changes in binary files. Yes, but it's too easy to forget the awkward "--no-commit" option. "patch" doesn't involve such quirks. > patch doesn?t > do anything useful with that information, and also requires downloading and > setup on Windows. Well, chances are TortoiseHG comes with an UI to apply patches (TortoiseSVN had one), so the command-line instructions may be of little use to them. 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] hg extensions was Mercurial conversion repositories
On Sun, 27 Feb 2011 07:46:51 +0100 "Martin v. Löwis" wrote: > > Actually, it isn't *required* on each developer's setup, since we > > now have a hook that refuses bogus changegroups (if needed, we can even > > refuse individual changesets). In most situations, even without the > > eol extension line endings won't get modified anyway. > > I think this is overly optimistic. Visual Studio will break all your > files if you don't use that extension (and you actually use it to > modify source code). My assumption was that most developers don't use MSVC, so most of them don't risk breaking eols ;) True, for Windows devs it might be necessary to promote 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
On Sun, 27 Feb 2011 08:09:21 +0100 "Martin v. Löwis" wrote: > >> changeset: 72694:e65daae6cf44 > >> user:Antoine Pitrou > >> date:Mon Feb 21 21:30:55 2011 + > >> summary: Try s/UINT_MAX/INT_MAX/ > > > > It's not on an unnamed branch, it's on the "default" branch (which 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] [Python-checkins] devguide: List common gotchas people might come across when doing coverage work.
On Sun, Feb 27, 2011 at 06:31, brett.cannon wrote: > +When writing new tests to increase coverage, do take note of the style of > tests > +already provided for a module (e.g., whitebox, blackbox, etc.). As > +some modules are primarily maintained by a single core developer they may > have > +a specific preference as to what kind of test is used (e.g., whitebox) and > +prefer that other types of tests not be used (e.g., blackbox). When in doubt, > +stick with whitebox testing in order to properly exercise the code. Do you think it could be nice to have a reference to what whitebox/blackbox testing is, ie http://en.wikipedia.org/wiki/White-box_testing http://en.wikipedia.org/wiki/Black-box_testing ? Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ 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] [Python-checkins] devguide (hg_transition): patchcheck does work
On Sun, Feb 27, 2011 at 03:17, eric.araujo wrote: > eric.araujo pushed f325d743c385 to devguide: > > http://hg.python.org/devguide/rev/f325d743c385 > changeset: 331:f325d743c385 > branch: hg_transition > user: ?ric Araujo > date: Sat Feb 26 17:30:51 2011 +0100 > summary: > patchcheck does work > > files: > patch.rst > > diff --git a/patch.rst b/patch.rst > --- a/patch.rst > +++ b/patch.rst > @@ -114,15 +114,13 @@ > Generation > '' > > -.. XXX [commented out] make patchcheck doesn't work with non-SVN workflow > +To perform a quick sanity check on your patch, you can run:: > > - To perform a quick sanity check on your patch, you can run:: > + make patchcheck > > - make patchcheck > - > - This will check and/or fix various common things people forget to do for > - patches, such as adding any new files needing for the patch to work (do > not > - that not all checks apply to non-core developers). > +This will check and/or fix various common things people forget to do for > +patches, such as adding any new files needing for the patch to work (do not (do note Cheers, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ 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] of branches and heads
On 2011-02-26 23:26, Greg Ewing wrote:
> From: Antoine Pitrou
>> - a "branch" usually means a "named branch": a set of changesets
>> bearing the same label (e.g. "default"); that label is freely chosen
>> by the committer at any point, and enforces no topological
>> characteristic
>
> There are *some* topological restrictions, because hg won't
> let you assign a branch name that's been used before to a node
> unless one of its parents has that name. So you can't create
> two disconnected subgraphs whose nodes have the same branch
> name.
That's not completely correct. You *can* do that.
Mercurial by default assumes you're probably in error if you are
trying to create such disconnected branch name subgraphs, but you
can convince it that it's really what you want by doing:
hg branch --force
Example (glog command requires the graphlog extension enabled [1]):
$ hg init a
$ cd a
$ echo foo > bla
$ hg ci -Am1
adding bla
$ hg branch b1
marked working directory as branch b1
$ hg ci -m2
$ hg branch default
abort: a branch of the same name already exists (use 'hg update' to switch to
it)
$ hg branch --force default
marked working directory as branch default
$ hg ci -m3
created new head
$ hg glog --template "{rev}, {branch}\n"
@ 2, default
|
o 1, b1
|
o 0, default
[1] http://mercurial.selenic.com/wiki/GraphlogExtension
___
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] set iteration order
>> It's not a matter of dependence on iteration order, but of >> reproducibility (in my case there were minor numerical differences due >> to different iteration orders). > > Can you give a code example? I don’t understand your case. It's a bit involved (that's why it took me a while to locate the difference in behavior), but it boils down to a (learning) algorithm that in principle should not care about order of input data, but will in practice show slightly different numerical behavior. I ran into the problem when trying to exactly reproduce previously published experimental results. Of course, I should have anticipated this and fixed some arbitrary order in the first place. I just thought a note about this change might save someone in a similar situation some confusion. Cheers, Hagen ___ 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
