This fixes mistake of documentation about matching against directories
in "pattern.txt" introduced by b99923dc748f.
".hgignore" treats specified "glob:" pattern as same as one specified
for "-X" option: it can match against directories, too.
For reference, extra regexp string appended to specified pattern for
each types are listed below: see also "match.match()" and
"match._regex()" for detail.
============= ========== ===============
type cmdline -I/-X
============= ========== ===============
glob/relglob '$' '(?:/|$)'
path/relpath '(?:/|$)' '(?:/|$)'
re/relre (none) (none)
============= ========== ===============
Appending '$' means that the specified pattern should match against
only files.
Before this patch, shell alias may be executed by abbreviated command
name unexpectedly, even if abbreviated command name matches also
against the command provided by extension.
For example, "rebate" shell alias is executed by "hg reba", even if
rebase extension (= "rebase" command) is enabled. In this case, "hg
reba" should be aborted because of command name ambiguity.
This patch makes "_checkshellalias()" invoke "cmdutil.findcmd()"
always with "strict=True" (default value).
If abbreviated command name matches against only one shell alias even
after loading extensions, such shell alias will be executed via
"_parse()".
This patch doesn't remove "_checkshellalias()" invocation itself,
because it may prevent shell alias from loading extensions uselessly.
When generating documentation, indentation must match for getting the same
view for translated messages. Often an output is generated anyway, but it
can look different. When a syntactically wrong indentation change is done,
runrst will fail (this is detected by test-gendoc.t).
Fix the simple places. When translation knowledge is necessary, the entry is
marked as fuzzy (and therefore skipped when generating translations). A
translator can fix it later.
.. note:: is rst syntax which must not be translated. Fix this in the
translations.
This is not the first time this happens, so there should be a note for the
translator. A later patch will change the generation of the po files to
write this automatically.
A test in i18n/check-translation.py could help as well.
Strip the locations by running msgcat [1] as the wiki [2] tells to do. Do
this in a separate patch for getting a smaller one when updating from hg.pot.
[1] msgcat --no-location -o de.po de.po
[2] mercurial.selenic.com/wiki/TranslatingMercurial#Updating_a_Translation
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.
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.
This methods are intended to duck-type baseset, so we will still have _addset
as a private class but now we can return it without wrapping it into an
orderedlazyset or a lazyset.
These were the last methods to add for smartset compatibility.
This method is intended to duck-type baseset, so we will still have _addset as a
private class but we will be able to return it without wrapping it into an
orderedlazyset or a lazyset.
This method is intended to duck-type baseset, so we will still have _addset as a
private class but now will be able to return it without wrapping it into an
orderedlazyset or a lazyset.
This method is intended to duck-type baseset, so we will still have _addset as a
private class but we will be able to return it without wrapping it into an
orderedlazyset or a lazyset.
This methods are intended to duck-type baseset, so we will still have _addset
as a private class but will be able return it without wrapping it into an
orderedlazyset or a lazyset.
This method is intended to duck-type baseset, so we will still have _addset
as a private class but we will be able return it without wrapping it into an
orderedlazyset or a lazyset.
This methods state if the class is sorted in an ascending or descending order
We need this to implement methods based on order on smartset classes in order
to be able to create new objects with a given order.
We cannot just rely on a simple boolean since unordered set are neither
ascending nor descending.
We need this method to duck-type generatorset since this class is not going to
be used outside revset.py and we don't need to duck-type baseset.
This sort method will only do something when the addset is not already sorted
or is not sorted in the way we want it to be.
If the two collections are in ascending order, yield their values in an
ordered way by iterating both at the same time and picking the values to
yield.
When a spanset was being sorted it didn't take into account it's current
state (ascending or descending) and it reversed itself everytime the reverse
parameter was True.
This is not yet used but it will be as soon as the sort revset is changed to
directly use the structures sort method.
Previously the head() revset would iterate over every item in the subset and
check if it was a head. Since the subset is often the entire repo, this was
slow on large repos. Now we iterate over each item in the head list and check if
it's in the subset, which results in much less work.
hg log -r 'head()' on a large repo:
Before: 0.95s
After: 0.28s
Since this class is only going to be used inside revset.py (it does not duck
type baseset) it needs to duck type only a few more methods for the next
patches.
This class is not supposed to be used outside revset.py since it only
wraps content that is used by baseset typed classes.
It only gets created by revset operations or private methods.
This class is not supposed to be used outside revset.py since it only
wraps content that is used by baseset typed classes.
It only gets created by revset operations or private methods.
This class is not supposed to be used outside revset.py since it only
wraps content that is used by baseset typed classes.
It only gets created by revset operations or private methods.
