Summary:
See the previous diff (D15291676) for motivation. Basically, it's hard to keep
static resources work well with 3 different kinds of deployments (buck xar,
Windows zip, and python side-packages).
This diff just precomputes common styles and hardcoded them in Python code.
This should address a user complaint that `-T xml` does not work.
Reviewed By: markbt
Differential Revision: D15307457
fbshipit-source-id: de4edb0b6896b731301715abe612a31b1512b00a
Summary:
Clean up things:
- Build scripts. They are probably broke. We have different build scripts.
- hgk. Probably broken.
- docker. We won't maintain hgweb as-is.
- Utilities from fb-hgext. They are no longer used.
Reviewed By: kulshrax
Differential Revision: D15327228
fbshipit-source-id: 3568f20ddce6b364a46d306d95279b7faaef9f82
Summary:
It's a headache about how to deal with static files (help/, template/, default
config), since we have 3 different ways of packing the Python code: normal
(linux), embedded (Windows), and fbcode xar (linux). The latter two need
workarounds to make `help/` work, and for the "embedded" case, It is currently
broken.
This diff moves user-facing `help/` files to a Python module to remove the need
of special casing it in different ways.
`helptext.py` was created via:
import glob, os
for path in glob.glob('help/*.txt'):
if path.count('.') == 1:
name = path.split('.')[0]
name = os.path.basename(name)
if '-' in name:
name = 'globals()[%r]' % name
print("%s = r'''%s'''\n\n" % (name, open(path, "rb").read()))
os.unlink(path)
The help text about named branches are removed to make `test-check-help.t`
happy.
Reviewed By: mitrandir77
Differential Revision: D15291676
fbshipit-source-id: 2320bd59369ef092d8c06b8539e401799a0467ef
Summary:
Disable parsing `.hgignore` and related fileset `hgignore()` by default. They can
still be enabled via configuration. The plan is to completely remove them
later.
A replacement for `hgignore()` fileset was added as `gitignore()`.
The `hgignore()` fileset seems to be only used by zertosh in the past 3 months.
Reviewed By: singhsrb
Differential Revision: D14543232
fbshipit-source-id: f2385062a0e816331f693239f62448979876078a
Summary:
Move top-level Python packages `mercurial`, `hgext` and `hgdemandimport` to
a new top-level package `edenscm`. This allows the Python packages provided by
the upstream Mercurial to be installed side-by-side.
To maintain compatibility, `edenscm/` gets added to `sys.path` in
`mercurial/__init__.py`.
Reviewed By: phillco, ikostia
Differential Revision: D13853115
fbshipit-source-id: b296b0673dc54c61ef6a591ebc687057ff53b22e
Summary:
So the use of `os.path.dirname(__file__)` which won't work in buck
python binary can be removed.
Reviewed By: DurhamG
Differential Revision: D6881306
fbshipit-source-id: b6504beaf07fe9853abff08b9721a17b31ac7515
Summary:
The `lib/linelog` directory contains pure C code that is unrelated from
either Mercurial or Python. The `mercurial/cyext` contains Cython extension
code (although for linelog's case, the Cython extension is unrelated from
Mercurial).
Cython is now a hard dependence to simplify the code.
Test Plan: `make local` and check `from mercurial.cyext import linelog` works.
Reviewers: durham, #mercurial
Reviewed By: durham
Subscribers: durham, fried
Differential Revision: https://phabricator.intern.facebook.com/D6678541
Signature: 6678541:1515455512:967266dc69c702dbff95fdea05671e11c32ebf28
encoding.fromlocal() never tries to decode an ascii string since 3cb2361c60fc,
and there's no universal non-ascii string which can be decoded as any valid
character set.
Most test scripts use "hg" to interact with a temporary test repository.
However a few tests also want to run hg commands to interact with the local
repository containing the mercurial source code. Notably, many of the
test-check-* tests want to check local files and commit messages.
These tests were previously using the version of hg being tested to query the
source repository. However, this will fail if the source repository requires
extensions or other settings not supported by the version of mercurial being
tested. The source repository was typically initially cloned using the system
hg installation, so we should use the system hg installation to query it.
There was already a helpers-testrepo.sh script designed to help cope with
different requirements for the source repository versus the test repositories.
However, it only handled the evolve extension. This new behavior works with
any extensions that are different between the system installation and the test
installation.
pip will check to see if it's the latest version, and complain if it isn't.
The --no-index flag implies the --disable-pip-version-check flag, and makes
the warning (and any associated network activity) go away.
Since we're doing so much clever junk in our setup.py, let's have a
test that exercises it.
Thanks to Matt Harbison for testing this on Windows and verifying that
installenv/*/hg would work as a way to work around bin being called
Scripts on Windows.
This commit introduces support for advertising a server's support for
media types and compression formats in accordance with the spec defined
in internals.wireproto.
The bulk of the new code is a helper function in wireproto.py to
obtain a prioritized list of compression engines available to the
wire protocol. While not utilized yet, we implement support
for obtaining the list of compression engines advertised by the
client.
The upcoming HTTP protocol enhancements are a bit lower-level than
existing tests (most existing tests are command centric). So,
this commit establishes a new test file that will be appropriate
for holding tests around the functionality of the HTTP protocol
itself.
Rounding out this change, `hg debuginstall` now prints compression
engines available to the server.
Since compression engines may be provided by extensions and since
not all registered compression engines may be available to use,
it seems useful to provide a mechanism to see the state of known
compression engines.
This commit teaches `hg debuginstall` to print info on known and
available compression engines.
Over the past week I've had to instruct multiple people to run
Python code to query the ssl module to see what TLS protocol support
is present. I think it would be useful for `hg debuginstall` to print
this info to make it easier to access and debug why Mercurial is
complaining about using an insecure TLS 1.0 protocol.
Ideally we'd also print the path to the CA cert bundle. But the APIs
for querying that in sslutil can emit warnings, making it slightly
more difficult to integrate into `hg debuginstall`. That work will
have to wait for another day.
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)