This corrects a warning from lintian that we're shipping an executable without
a man page. Since there is a doc string in the text, let's use that for the man
page.
Although this is coming in under the guise of consistency, part of the
desire for this is that at least as part of the official Solaris builds,
we build with a versioned python interpreter, such as "python2.7", which
doesn't match "*python".
This makes the changes in 68b7b759ebff and 71a3703364df available on Windows.
I'm not setup to make the installer, so someone with experience in this area
should probably give it a look. In looking around to try to figure out how to
build the installer, it looks like the Makefile may need an update to $DOCFILES.
It seems like a good idea to document the revlog format.
There is a lot more that could be added to this documentation.
But you have to start somewhere.
This would have caught the problem fixed by 47bcbe06a48d. There are
other *.wxs files that can be checked, but they appear to be more
complicated. For example, locale.wxs has what appears to be foreach
loop support, as well as variable substitution.
By checking `hg files` to determine tracked file, this is able to avoid false
failures when other junk is present in the filesystem, like *.orig files.
I can't tell if the map-cmdline.status file is not included on purpose, but I
don't see the purpose of excluding it. The missing help files seem reasonable
for Windows.
The editor launches without expanding the path with commits because the shell
does that for us.
If the path isn't an executable, the expanded path is displayed, which is
probably more useful than the unexpanded path. For example, in cmd.exe, '~'
expands to C:\Users\$user. But it expands to C:/mingw/msys/1.0/home/$user in
MinGW.
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.
Globbing is usually used for filenames, so on windows it is reasonable and very
convenient that glob patterns accepts '\' or '/' when the pattern specifies
'/'.
Why?
- Mercurial internal patcher works correctly for regular patches and git
patches, is much faster at least on Windows and is more extensible.
- In theory, the external patcher can be used to handle exotic patch formats. I
do not know any and have not heard about any such use in years.
- Most patch programs cannot handle git format patches, which makes the API
caller to decide either to ignore ui.patch by calling patch.internalpatch()
directly, or take the risk of random failures with valid inputs.
- One thing a patch program could do Mercurial patcher cannot is applying with
--reverse. Apparently several shelve like extensions try to use that,
including passing the "reverse" option to Mercurial patcher, which has been
removed mid-2009. I never heard anybody complain about that, and would prefer
reimplementing it anyway.
And from the technical perspective:
- The external patcher makes everything harder to maintain and implement. EOL
normalization is not implemented, and I would bet file renames, if supported
by the patcher, are not correctly recorded in the dirstate.
- No tests.
How?
- Remove related documentation
- Clearly mark patch.externalpatch() as private
- Remove the debuginstall check. This deprecation request was actually
triggered by this last point. debuginstall is the only piece of code patching
without a repository. When migrating to an integrated patch() + updatedir()
call, this was really a showstopper, all workarounds were either ugly or
uselessly complicated to implement. If we do not support external patcher
anymore, the debuginstall check is not useful anymore.
- Remove patch.externalpatch() after 1.9 release.
This adds a " (glob)" marker that works like a simpler version of
(re): "*" is converted to ".*", and "?" is converted to ".".
Both special characters can be escaped using "\", and the backslash
itself can be escaped as well.
Other glob-style syntax, like "**", "[chars]", or "[!chars]", isn't
supported.
Consider this test:
$ hg glog --template '{rev}:{node|short} "{desc}"\n'
@ 2:20c4f79fd7ac "3"
|
| o 1:38f24201dcab "2"
|/
o 0:2a18120dc1c9 "1"
Because each line beginning with "|" can be compiled as a regular
expression (equivalent to ".*|"), they will match any output.
Similarly:
$ echo foo
The blank output line can be compiled as a regular expression and will
also match any output.
With this patch, none of the above output lines will be matched as
regular expressions. A line must end in " (re)" in order to be matched
as one.
Lines are still matched literally first, so the following will pass:
$ echo 'foo (re)'
foo (re)
