FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 19 Mar 2014 01:07:41 +0900] rev 20771
amend: save commit message into ".hg/last-message.txt"
Before this patch, commit message (may be manually edited) for "commit
--amend" is never saved into ".hg/last-message.txt", because it uses
"localrepository.commitctx()" instead of "localrepository.commit()":
saving into ".hg/last-message.txt" is executed only in the latter.
This patch saves commit message for "commit --amend" into
".hg/last-message.txt" just after user editing.
This is the simplest implementation to fix on stable. Editing and
saving commit message for memctx should be centralized into the
framework like "localrepository.commit()" with "editor" argument or so
in the future.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 19 Mar 2014 01:07:41 +0900] rev 20770
histedit: save manually edited commit message into ".hg/last-message.txt"
Before this patch, manually edited commit message for "fold" command
in histedit-ing is never saved into ".hg/last-message.txt", because it
uses "localrepository.commitctx()" instead of
"localrepository.commit()": saving into ".hg/last-message.txt" is
executed only in the latter.
This patch saves manually edited commit message for "fold" command in
histedit-ing into ".hg/last-message.txt" just after user editing.
This is the simplest implementation to fix on stable. Editing and
saving commit message for memctx should be centralized into the
framework like "localrepository.commit()" with "editor" argument or so
in the future.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 19 Mar 2014 01:07:41 +0900] rev 20769
qfold: save manually edited commit message into ".hg/last-message.txt"
Before this patch, manually edited commit message for "hg qfold -e"
isn't saved into ".hg/last-message.txt" until it is saved by
"localrepository.savecommitmessage()" in "localrepository.commit()".
This may lose such commit message, if unexpected exception is raised.
This patch saves manually edited commit message for "hg qfold -e" into
".hg/last-message.txt" just after user editing. This patch doesn't
save the message specified by -m/-l options as same as other commands.
This is the simplest implementation to fix on stable. Editing and
saving commit message should be centralized into the framework of
"localrepository.commit()" with "editor" argument in the future.
This patch uses repository wrapping class for exception raising before
saving commit message in "localrepository.commit()" easily and
certainly, because such exception requires corner case condition.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 19 Mar 2014 01:07:41 +0900] rev 20768
qnew: save manually edited commit message into ".hg/last-message.txt"
Before this patch, manually edited commit message for "hg qnew -e"
isn't saved into ".hg/last-message.txt" until it is saved by
"localrepository.savecommitmessage()" in "localrepository.commit()".
This may lose such commit message, if unexpected exception is raised.
This patch saves manually edited commit message for "hg qnew -e" into
".hg/last-message.txt" just after user editing. This patch doesn't
save the message specified by -m/-l options as same as other commands.
This is the simplest implementation to fix on stable. Editing and
saving commit message should be centralized into the framework of
"localrepository.commit()" with "editor" argument in the future.
This patch uses repository wrapping class for exception raising before
saving commit message in "localrepository.commit()" easily and
certainly, because such exception requires corner case condition.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 19 Mar 2014 01:07:41 +0900] rev 20767
tag: save manually edited commit message into ".hg/last-message.txt"
Before this patch, manually edited commit message for "hg tag -e"
isn't saved into ".hg/last-message.txt" until it is saved by
"localrepository.savecommitmessage()" in "localrepository.commit()".
This may lose such commit message, if unexpected exception is raised.
This patch saves manually edited commit message for "hg tag -e" into
".hg/last-message.txt" just after user editing. This patch doesn't
save the message specified by -m option (-l is not supported for "hg
tag") as same as other commands.
This is the simplest implementation to fix on stable. Editing and
saving commit message should be centralized into the framework of
"localrepository.commit()" with "editor" argument in the future.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 19 Mar 2014 01:07:41 +0900] rev 20766
rebase: use "commitforceeditor" instead of "ui.edit()" for "--collapse"
Before this patch, "rebase --collapse --edit" without "--message" and
"--logfile" invokes editor twice unexpectedly:
1. explicit "ui.edit()" invocation in rebase extension itself
2. indirect invocation in "localrepository.commit()" with "editor =
commitforceeditor" assigned by "--edit" option
This patch uses indirect "commitforceeditor" invocation instead of
"ui.edit()" for "--collapse" without "--message" and "--logfile" to:
- suppress redundant the former invocation
- ensure editor invocation even when "--edit" is not specified
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 19 Mar 2014 01:07:41 +0900] rev 20765
localrepo: save manually edited commit message as soon as possible
Before this patch, "localrepository.commit()" invokes specified
"editor" to edit commit message manually, and saves it after checking
sub-repositories.
This may lose manually edited commit message, if unexpected exception
is raised while checking (or commiting recursively) sub-repositories.
This patch saves manually edited commit message as soon as possible.
Andrew Shadura <andrew@shadura.me> [Sat, 15 Mar 2014 15:44:51 +0100] rev 20764
hgk: enable selected patch text on Windows
Port a patch from gitk. Original description:
On windows, mouse input follows the keyboard focus, so to allow selecting
text from the patch canvas we must not shift focus back to the top level.
This change has no negative impact on X, so we don't explicitly test
for Win32 on this change. This provides similar selection capability
as already available using X-Windows.
Signed-off-by: Mark Levedahl <mdl123@verizon.net>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Andrew Shadura <andrew@shadura.me> [Sat, 15 Mar 2014 15:33:50 +0100] rev 20763
hgk: ignore ctrl-z as EOF on windows
Port a patch from gitk. Original description:
Cygwin's Tcl is configured to honor any occurence of ctrl-z as an
end-of-file marker, while some commits in the git repository and possibly
elsewhere include that character in the commit comment. This causes gitk
ignore commit history following such a comment and incorrect graphs. This
change affects only Windows as Tcl on other platforms already has
eofchar == {}. This fixes problems noted by me and by Ray Lehtiniemi, and
the fix was suggested by Shawn Pierce.
Signed-off-by: Mark Levedahl <mdl123@verizon.net>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Lucas Moscovicz <lmoscovicz@fb.com> [Fri, 14 Mar 2014 08:46:46 -0700] rev 20762
graphmod: changed code in dagwalker to use lazy implementations
Used lazy methods when possible.
Lucas Moscovicz <lmoscovicz@fb.com> [Fri, 14 Mar 2014 08:47:57 -0700] rev 20761
webcommands: changed code to use lazy classes when calling dagwalker
This needs to be changed to use a baseset since dagwalker now expects to
receive a smartset. This is basically wrapping revs into a baseset to be
compatible with smartset implementations.
Lucas Moscovicz <lmoscovicz@fb.com> [Fri, 14 Mar 2014 13:27:12 -0700] rev 20760
cmdutil: changed max method for lazy call
Used the lazy max call instead of the python max implementation to be able to
use lazysets for graphlog.
Lucas Moscovicz <lmoscovicz@fb.com> [Fri, 14 Mar 2014 13:26:40 -0700] rev 20759
getgraphlogrevs: return an empty baseset instead of a empty list
We aims at returning smartset only so that function higher in the stack can use
smartset feature.
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 14 Mar 2014 16:26:50 -0700] rev 20758
getgraphlogrevs: do not convert smartset to baseset
We are now sure that revs is a smartset. We remove the baseset call that would
defeat any lazyness.
Lucas Moscovicz <lmoscovicz@fb.com> [Fri, 14 Mar 2014 08:44:52 -0700] rev 20757
cmdutil: changed revset for spanset
Instead of using baseset(repo.changelog) changed it for spanset(repo) which is
much faster.
Lucas Moscovicz <lmoscovicz@fb.com> [Fri, 14 Mar 2014 11:35:17 -0700] rev 20756
cmdutil: changed code in _makegraphlogrevset not to use getitem
__getitem__ is a method that is not implemented lazily on many of the new
classes and it can be easily replaced with a structure that takes advantage of
the new lazy implementations instead.
Lucas Moscovicz <lmoscovicz@fb.com> [Fri, 14 Mar 2014 08:43:52 -0700] rev 20755
cmdutil: changed code in getgraphlogrevs not to use getitem
__getitem__ is a method that is not implemented lazily on many of the new
classes and it can be easily replaced with a structure that takes advantage of
the new lazy implementations instead.
Lucas Moscovicz <lmoscovicz@fb.com> [Tue, 18 Feb 2014 11:35:03 -0800] rev 20754
revset: changed minrev and maxrev implementations to use ordered sets
Performance Benchmarking:
0) max(tip:0)
1) min(0:tip)
2) min(0::)
b96cb15ec9e0 (2.9.1 release)
0) ! wall 0.005699 comb 0.000000 user 0.000000 sys 0.000000 (best of 450)
1) ! wall 0.005414 comb 0.010000 user 0.010000 sys 0.000000 (best of 493)
2) ! wall 0.025951 comb 0.030000 user 0.030000 sys 0.000000 (best of 107)
05267e6e94dd (public tip at submission time)
0) ! wall 0.015177 comb 0.020000 user 0.020000 sys 0.000000 (best of 175)
1) ! wall 0.014779 comb 0.010000 user 0.010000 sys 0.000000 (best of 189)
2) ! wall 12.345179 comb 12.350000 user 12.350000 sys 0.000000 (best of 3)
Current patches:
0) ! wall 0.001911 comb 0.000000 user 0.000000 sys 0.000000 (best of 1357)
1) ! wall 0.001943 comb 0.010000 user 0.010000 sys 0.000000 (best of 1406)
2) ! wall 0.000405 comb 0.000000 user 0.000000 sys 0.000000 (best of 6761)
Lucas Moscovicz <lmoscovicz@fb.com> [Fri, 14 Mar 2014 14:43:44 -0700] rev 20753
revset: changed addset to extend _orderedsetmixin
Now _addset can use the lazy min and max implementation.
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 14 Mar 2014 11:41:26 -0700] rev 20752
revset: add a default argument for baseset.__init__
We are now able to create empty baseset using `baseset()` as we are able to
create empty list with `list()`.
Lucas Moscovicz <lmoscovicz@fb.com> [Thu, 13 Mar 2014 11:36:45 -0700] rev 20751
revset: changed orderedlazyset to also extend _orderedsetmixin
Now orderedlazyset can use the lazy min and max implementation.
Lucas Moscovicz <lmoscovicz@fb.com> [Thu, 13 Mar 2014 11:36:11 -0700] rev 20750
revset: changed spanset to extend _orderedsetmixin
Now spanset can use the lazy min and max methods implementation.
Lucas Moscovicz <lmoscovicz@fb.com> [Wed, 12 Mar 2014 16:40:18 -0700] rev 20749
revset: added _orderedsetmixin class
This class has utility methods for any ordered class to get the min and the
max values.
Lucas Moscovicz <lmoscovicz@fb.com> [Wed, 19 Feb 2014 09:28:17 -0800] rev 20748
revset: added min and max methods to baseset and lazyset
This classes have no particular order so they rely on python min() and max()
implementation. This methods will be implemented in every smartset class in
future patches. For other classes there are lazy implementations that can be
made for this methods.
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 14 Mar 2014 15:47:29 -0700] rev 20747
contrib: make revset benchmark script able to read from stdin
This help fine control of what we want to benchmark
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 14 Mar 2014 15:43:55 -0700] rev 20746
contrib: have the revset benchmark test script take a revset
The script now selection revision to run benchmark against using a revset query
instead of a revision range.
It is expected that people benchmarking revset have some knowledge of revset.
Lucas Moscovicz <lmoscovicz@fb.com> [Fri, 14 Mar 2014 11:24:59 -0700] rev 20745
contrib: added revset performance benchmarking script
This script takes two arguments (starting revision, ending revision) and tests
for each revision in between the entire list of revsets in the script using
perfrevset.
Lucas Moscovicz <lmoscovicz@fb.com> [Fri, 14 Mar 2014 15:00:15 -0700] rev 20744
contrib: added revset examples for benchmarking performance
Added list of revsets used for benchmarking revset performance so far.
Simon Heimberg <simohe@besonet.ch> [Mon, 17 Feb 2014 07:39:53 +0100] rev 20743
help: filter out deprecated options with untranslated descriptions
When using a different language than English, deprecated options were only
removed from the output of `hg help anycmd` when "DEPRECATED" in the options
description was translated.
Chris Jerdonek <chris.jerdonek@gmail.com> [Wed, 04 Dec 2013 20:38:27 -0800] rev 20742
parsers: fail fast if Python has wrong minor version (issue4110)
This change causes an informative ImportError to be raised when importing
the parsers extension module if the minor version of the currently-running
Python interpreter doesn't match that of the Python used when compiling
the extension module.
This change also exposes a parsers.versionerrortext constant in the
C implementation of the module. Its presence can be used to determine
whether this behavior is present in a version of the module. The value
of the constant is the leading text of the ImportError raised and is set
to "Python minor version mismatch".
Here is an example of what the new error looks like:
Traceback (most recent call last):
File "test.py", line 1, in <module>
import mercurial.parsers
ImportError: Python minor version mismatch: The Mercurial extension
modules were compiled with Python 2.7.6, but Mercurial is currently using
Python with sys.hexversion=33883888: Python 2.5.6
(r256:88840, Nov 18 2012, 05:37:10)
[GCC 4.2.1 Compatible Apple Clang 4.1 ((tags/Apple/clang-421.11.66))]
at: /opt/local/Library/Frameworks/Python.framework/Versions/2.5/Resources/
Python.app/Contents/MacOS/Python
The reason for raising an error in this scenario is that Python's C API
is known not to be compatible from minor version to minor version, even
if sys.api_version is the same. See for example this Python bug report
about incompatibilities between 2.5 and 2.6+:
http://bugs.python.org/issue8118
These incompatibilities can cause Mercurial to break in mysterious,
unforeseen ways. For example, when Mercurial compiled with Python 2.7 was
run with 2.5, the following crash occurred when running "hg status":
http://bz.selenic.com/show_bug.cgi?id=4110
After this crash was fixed, running with Python 2.5 no longer crashes, but
the following puzzling behavior still occurs:
$ hg status
...
File ".../mercurial/changelog.py", line 123, in __init__
revlog.revlog.__init__(self, opener, "00changelog.i")
File ".../mercurial/revlog.py", line 251, in __init__
d = self._io.parseindex(i, self._inline)
File ".../mercurial/revlog.py", line 158, in parseindex
index, cache = parsers.parse_index2(data, inline)
TypeError: data is not a string
which can be reproduced more simply with:
import mercurial.parsers as parsers
parsers.parse_index2("", True)
Both the crash and the TypeError occurred because the Python C API's
PyString_Check() returns the wrong value when the C header files from
Python 2.7 are run with Python 2.5. This is an example of an
incompatibility of the sort mentioned in the Python bug report above.
Failing fast with an informative error message results in a better user
experience in cases like the above. The information in the ImportError
also simplifies troubleshooting for those on Mercurial mailing lists, the
bug tracker, etc.
This patch only adds the version check to parsers.c, which is sufficient
to affect command-line commands like "hg status" and "hg summary".
An idea for a future improvement is to move the version-checking C code
to a more central location, and have it run when importing all
Mercurial extension modules and not just parsers.c.
Matt Mackall <mpm@selenic.com> [Fri, 14 Mar 2014 16:00:11 -0500] rev 20741
debuginstall: change showing to checking for consistency and future checking
Chris Jerdonek <chris.jerdonek@gmail.com> [Tue, 31 Dec 2013 00:37:16 -0800] rev 20740
debuginstall: add Python information to debuginstall output (issue4128)
This change adds to the output of "hg debuginstall" information about the
Python being used by Mercurial. It adds both the path to the Python
executable (i.e. the value of sys.executable) and the version of Python
(specifically the major, minor, and micro versions).
Below is an example of what the output looks like after this change.
The marked lines are the new output lines:
$ hg debuginstall
checking encoding (UTF-8)...
-->showing Python executable (/Users/chris/.virtualenvs/default/bin/python)
-->showing Python version (2.7.6)
checking Python lib (/Users/chris/.virtualenvs/default/lib/python2.7)...
checking installed modules (/Users/chris/mercurial)...
checking templates (/Users/chris/mercurial/templates)...
checking commit editor...
checking username...
no problems detected
Note that we use the word "showing" without an ellipsis for the new lines
because, unlike the other lines (except for "Python lib" which will be
adjusted in a subsequent commit), no check follows the display of this
information.