- Mar 06, 2019
-
-
Pierre-Yves David authored
The goal is to clarify each section goal.
-
Pierre-Yves David authored
Relying on the fact None is treated as 0 by other logics seems smarter than we should be.
-
Pierre-Yves David authored
I expect the docstring to grow over time, so lets start small.
-
Pierre-Yves David authored
The method is for internal use only.
-
Pierre-Yves David authored
Simple method, get simple documentation.
-
Pierre-Yves David authored
The method is for internal use only.
-
Pierre-Yves David authored
Simple method get simple documentation.
-
Pierre-Yves David authored
The method is for internal use only. Let us make that fact clearer.
-
Pierre-Yves David authored
This is the first bit of an effort to document and augment the verify code.
-
- Mar 04, 2019
-
-
Navaneeth Suresh authored
This adds a flag `--allow-dirty-working-copy` as an alias for the experimental config option `experimental.uncommitondirtydir`. Differential Revision: https://phab.mercurial-scm.org/D6069
-
- Feb 11, 2019
-
-
Navaneeth Suresh authored
On a dirty PATH, uncommit was working without even setting the config `experimental.uncommitondirtydir` to `True`. Ideally, it should abort as it does for a dirty dir. This patch makes uncommit to require the config option `experimental.uncommitondirtydir` on a dirty PATH. Original patch to evolve extension authored by Dan Villiom Podlaski Christiansen: https://bitbucket.org/octobus/evolve-devel/pull-requests/8/bug-5977-uncommit-dirtiness/diff Differential Revision: https://phab.mercurial-scm.org/D5940
-
- Mar 05, 2019
-
-
Augie Fackler authored
I suspect one of these was a typo from the start, the other appears to have become a .t test at some point. Differential Revision: https://phab.mercurial-scm.org/D6076
-
- Mar 04, 2019
-
-
Pierre-Yves David authored
The attribute was introduce in 688fc33e105d, Yuya Nishihara pointed out that this preservation was missing. This changeset fixes the preservation and make sure we set the attribute according the modes.
-
Pierre-Yves David authored
The argument for `_lock` are non-trivial, having them passed explicitly makes thing clearer in my opinion. This is a Gratuitous change, I expect it will save me (and others) time in the future.
-
Gregory Szorc authored
w9xpopen.exe is a utility program shipped with Python <3.4 (https://bugs.python.org/issue14470 tracked its removal). The program was used by subprocess to wrap invoked processes on Windows 95 and 98 or when command.com was used in order to work around a redirect bug. The workaround is only used on ancient Windows versions - versions that we shouldn't see in 2019. While Python 2.7's subprocess module still references w9xpopen.exe, not shipping it shouldn't matter unless we're running an ancient version of Windows. Python will raise an exception if w9xpopen.exe can't be found. It's highly unlikely anyone is using current Mercurial releases on these ancient Windows versions. So remove w9xpopen.exe from the Inno installer. .. bc:: The 32-bit Windows Inno installers no longer distribute w9xpopen.exe. This should only impact people running Mercurial on Windows 95, 98, or ME. Differential Revision: https://phab.mercurial-scm.org/D6068
-
- Mar 03, 2019
-
-
Gregory Szorc authored
Ancient versions of Mercurial relied on pywin32 and I suspect that's why we have this dependency. We also ship the "keyring" package, which has a dependency on "pywin32-ctypes" (providing the "win32ctypes" package). This is a stripped down version of pywin32 that doesn't have as many dependencies. Since we don't have a dependency on pywin32 and since pywin32 is a bit annoying to package, let's get rid of it. With this change, py2exe no longers picks up DLL dependencies on various UCRT DLLs (because we no longer have a .pyd file beloning to pywin32 which was pulling them in). So, we were able to remove code in support of the UCRT DLLs. .. bc:: The Windows Inno installers no longer ship the pywin32 package. This package was being bundled for historical reasons. Mercurial stopped using pywin32 several years ago and the disappearance of this package should not have any meaningful impact. Differential Revision: https://phab.mercurial-scm.org/D6067
-
- Mar 04, 2019
-
-
Gregory Szorc authored
The official Inno installer build process is poorly documented. And attempting to reproduce behavior of the installer uploaded to www.mercurial-scm.org has revealed a number of unexpected behaviors. This commit attempts to improve the state of reproducibility of the Inno installer by introducing a Python script to largely automate the building of the installer. The new script (which must be run from an environment with the Visual C++ environment configured) takes care of producing an Inno installer. When run from a fresh Mercurial source checkout with all the proper system dependencies (the VC++ toolchain, Windows 10 SDK, and Inno tools) installed, it "just works." The script takes care of downloading all the Python dependencies in a secure manner and manages the build environment for you. You don't need any additional config files: just launch the script, pointing it at an existing Python and ISCC binary and it takes care of the rest. The produced installer creates a Mercurial installation with a handful of differences from the existing 4.9 installers (produced by someone else): * add_path.exe is missing (this was removed a few changesets ago) * The set of api-ms-win-core-* DLLs is different (I suspect this is due to me using a different UCRT / Windows version). * kernelbase.dll and msasn1.dll are missing. * There are a different set of .pyc files for dulwich, keyring, and pygments due to us using the latest versions of each. * We include Tcl/Tk DLLs and .pyc files (I'm not sure why these are missing from the existing installers). * We include the urllib3 and win32ctypes packages (which are dependencies of dulwich and pywin32, respectively). I'm not sure why these aren't present in the existing installers. * We include a different set of files for the distutils package. I'm not sure why. But it should be harmless. * We include the docutils package (it is getting picked up as a dependency somehow). I think this is fine. * We include a copy of argparse.pyc. I'm not sure why this was missing from existing installers. * We don't have a copy of sqlite3/dump.pyc. I'm not sure why. The SQLite C extension code only imports this module when conn.iterdump() is called. It should be safe to omit. * We include files in the email.test and test packages. The set of files is small and their presence should be harmless. The new script and support code is written in Python 3 because it is brand new and independent code and I don't believe new Python projects should be using Python 2 in 2019 if they have a choice about it. The readme.txt file has been renamed to readme.rst and overhauled to reflect the existence of build.py. Differential Revision: https://phab.mercurial-scm.org/D6066
-
- Mar 03, 2019
-
-
Gregory Szorc authored
When attempting to build the Inno installer locally, I was getting several file not found errors when py2exe was crawling DLL dependencies. The missing DLLs appear to be "internal" DLLs used by the Universal C Runtime (UCRT). In many cases, the missing DLLs don't appear to exist on my system at all! Some of the DLLs have version numbers that appear to be N+1 of what the existing version number is. Maybe the "public" UCRT DLLs are probing for version N+1 at load time and py2exe is picking these up? Who knows. This commit adds the non-public UCRT DLLs as found by py2exe on my system to the excluded DLLs set. After this change, I'm able to produce an Inno installer with an appropriate set of DLLs. Differential Revision: https://phab.mercurial-scm.org/D6065
-
Gregory Szorc authored
I'm attempting to reproduce the Inno installers on my local machine. As part of auditing differences between installer output, I noticed that the existing Inno installers include various 3rd party packages. There is no mention of this in the build instructions nor on the wiki. This must be something that is done by the installer producer. This commit teaches setup.py to include these 3rd party packages in py2exe's library. After this change, I am able to produce Inno installers that have a nearly identical set of Python modules. It's worth noting that pywin32 is included even though it probably shouldn't be. But including it is necessary in order to achieve parity with existing Inno installers. Differential Revision: https://phab.mercurial-scm.org/D6064
-
Gregory Szorc authored
Currently, various processes for packaging Mercurial state to manually invoke `make -C doc` in order to generate the documentation. This Makefile merely invokes `gendoc.py` and `runrst` to produce man pages and HTML pages. Not all environments may have the ability to easily run Makefiles. Windows is notably in this set. This commit ports the man page and HTML generation logic from doc/Makefile to setup.py. We introduce a new build_doc command which generates documentation by calling gendoc.py and runrst. The documentation can now be built via pure Python by running `python setup.py build_doc`. We don't implement dependency tracking because IMO it is more effort than it is worth. We could potentially remove the duplicated functionality in doc/Makefile. But I'm not sure what all is depending on it. So I plan to keep it around. # no-check-commit because forced foo_bar function names Differential Revision: https://phab.mercurial-scm.org/D6063
-
Gregory Szorc authored
According to the commit message for 0c35bb01a119, pywin32 was removed in Mercurial 1.8! Differential Revision: https://phab.mercurial-scm.org/D6062
-
Gregory Szorc authored
The inno distribution no longer includes cacert.pem as of ca1ad8ef38be (April 2015). The docs were never updated. Differential Revision: https://phab.mercurial-scm.org/D6061
-
- Feb 28, 2019
-
-
Gregory Szorc authored
While attempting to build the Inno installer, I was unable to find a copy of add_path.exe from the source site previously listed in the docs. Some quick Googling revealed that achieving this functionality in native Pascal scripts seems to be preferred these days. This commit vendors "Modify Path" (fetched from https://www.legroom.net/software/modpath) and plugs it into our Inno config file per its instructions. The existing Inno installer appears to only modify PATH for the current user (as opposed to at the system level). I've maintained this behavior with Modify Path. Although it would be trivial to change or add checkboxes to control the behavior. I'll leave this as a follow-up. Differential Revision: https://phab.mercurial-scm.org/D6060
-
- Mar 04, 2019
-
-
Gregory Szorc authored
Let's isolate the inno installer files to their own directory so the separation between things is clearer. This required adjusting a few relative paths and references to the old directory. Differential Revision: https://phab.mercurial-scm.org/D6059
-
Pulkit Goyal authored
Differential Revision: https://phab.mercurial-scm.org/D6073
-
Pulkit Goyal authored
Otherwise the later fails on Python 3. Differential Revision: https://phab.mercurial-scm.org/D6072
-
Pulkit Goyal authored
This was a str before. Differential Revision: https://phab.mercurial-scm.org/D6071
-
Augie Fackler authored
Turns out with-eval-after-load is new in 24.4. Differential Revision: https://phab.mercurial-scm.org/D6074
-
Pulkit Goyal authored
We use bytes everywhere. Differential Revision: https://phab.mercurial-scm.org/D6070
-
- Feb 12, 2019
-
-
Jörg Sonnenberger authored
hgweb has the (undocument) configuration option web.view that allows restricting visible revisions to immutable. This is useful for serving the same storage as publishing and non-publishing repo. Add the new server.view option to serve the same purpose by changing the default behavior of `getdispatchrepo`. Drop the hard-coded 'served' filter in the batch handler of v1 of the wire proto, this is a left-over from the days before `getdispatchrepo` existed. Differential Revision: https://phab.mercurial-scm.org/D5946
-
- Mar 01, 2019
-
-
Pulkit Goyal authored
I have not called pycompat.bytestr() and rather converted the value there because I am starting to get concerned about the function call overhead of all this bytes to str or vice versa convert functions. Differential Revision: https://phab.mercurial-scm.org/D6042
-
- Mar 02, 2019
-
-
Martin von Zweigbergk authored
Differential Revision: https://phab.mercurial-scm.org/D6053
-
Gregory Szorc authored
Otherwise Python 2 will coerce a unicode to str, which fails on HGUNICODEPEDANTRY=1. Differential Revision: https://phab.mercurial-scm.org/D6052
-
Gregory Szorc authored
This prevents the internals of Python from coercing a unicode to str on Python 2 and makes tests run with HGUNICODEPEDANTRY=1 a lot happier. Differential Revision: https://phab.mercurial-scm.org/D6051
-
Gregory Szorc authored
Otherwise we will call str.encode() on Python 2, which is wrong. sysbytes() does encode('utf-8') on Python 3. But the source is guaranteed ASCII, so it shouldn't matter. With this change, `hg` now runs with `HGUNICODEPEDANTRY=1` set. However, several tests are failing. Differential Revision: https://phab.mercurial-scm.org/D6050
-
Gregory Szorc authored
Otherwise Python 2 will attempt to coerce unicode to str, which we don't want. Differential Revision: https://phab.mercurial-scm.org/D6049
-
Gregory Szorc authored
Otherwise it coerces automatically. Differential Revision: https://phab.mercurial-scm.org/D6048
-
Gregory Szorc authored
Otherwise Python 2 will coerce unicode to str. Differential Revision: https://phab.mercurial-scm.org/D6047
-
Gregory Szorc authored
Otherwise Python 2 will coerce unicode to str at module load time. We don't like automatic string coercions. Differential Revision: https://phab.mercurial-scm.org/D6046
-
- Feb 28, 2019
-
-
Martin von Zweigbergk authored
scmutil.cleanupnodes() schedules stripping to be done after the current transaction, so we can safely run it within the transaction. This also means that the phase will be updated within the transaction, which I believe means that the initial (possibly incorrect) phase will not visible. Differential Revision: https://phab.mercurial-scm.org/D6037
-