- Oct 12, 2021
-
-
Simon Sapin authored
Previously we stored the entire value from `stat_result.st_mode`, like dirstate-v1 does. However only the executable permission and type of file (only symbolic links and normal files are supported) are relevant to Mecurial. So replace this field with two bits in the existing bitfield byte. For now the unused space is left as padding, as it will be used for something else soon. Differential Revision: https://phab.mercurial-scm.org/D11635
-
- Oct 11, 2021
-
-
Simon Sapin authored
The negative marker values are not used anymore. Differential Revision: https://phab.mercurial-scm.org/D11634
-
- Oct 12, 2021
-
-
Simon Sapin authored
… instead of 64 bits, while keeping the sub-second presision. This brings the size of one timestamp from 12 bytes to 8 bytes. 31 bits is chosen instead of 32 because that’s already what happens for the mtime of files and symlinks, because dirstate-v1 uses negative i32 values as markers. Later we’ll add sub-second precision for file/symlink mtimes, making their dirstate-v2 representation the same as for directories. Differential Revision: https://phab.mercurial-scm.org/D11633
-
Simon Sapin authored
PackedTimestamp is now exclusively for dirstate-v2 serialization purpose. It contains unaligned big-endian integers. Timestamp is used everywhere else and contains native Rust integers. Differential Revision: https://phab.mercurial-scm.org/D11632
-
- Oct 11, 2021
-
-
Simon Sapin authored
Change it from how I previously thought C’s `timespec` works to how it actually works. The previous behavior was also buggy for timestamps strictly before the epoch but less than one second away from it, because two’s complement does not distinguish negative zero from positive zero. Differential Revision: https://phab.mercurial-scm.org/D11629
-
- Oct 12, 2021
-
-
Simon Sapin authored
Converting from Timestamp back to SystemTime was only used for equality comparison, but this can also be done on Timestamp values. Differential Revision: https://phab.mercurial-scm.org/D11631
-
- Oct 08, 2021
-
-
Simon Sapin authored
This makes the dirstate-v2 file format match dirstate-v1 for the order of `mode`, `size`, and `mtime`. This order does not matter as long as these components are handled through named fields/attributes in code, but in a few places we still have tuples so having the same order everywhere might help avoid a bug that might not be obvious since those components have the same type. Differential Revision: https://phab.mercurial-scm.org/D11620
-
- Oct 11, 2021
-
-
Simon Sapin authored
This file format modification was previously left incomplete because of planned upcoming changes. Not all of these changes have been made yet, but documenting what exists today will help talking more widely about it. Differential Revision: https://phab.mercurial-scm.org/D11625
-
- Sep 08, 2021
-
-
Raphaël Gomès authored
The changegroup fix was put in 5.9.1, this is now out of date. Alson, this can maybe encourage people to upgrade? Differential Revision: https://phab.mercurial-scm.org/D11392
-
- Mar 02, 2021
-
-
Martin von Zweigbergk authored
Among our users at Google, we're still seeing several percent of commands fail with exit code 255. I suspect keyboard interrupts is an important remaining reason. This is a resend of D10086 with some fixes for pager handling added ahead of it. Differential Revision: https://phab.mercurial-scm.org/D11628
-
- Oct 08, 2021
-
-
Martin von Zweigbergk authored
When the pager dies, we get a `SIGPIPE`. That causes `error.SignalInterrupt` to be raised ` (from `ui._catchterm()`). Any further writes or flushes will cause further `SIGPIPE`s and furhter `error.SignalInterrupt`. If we write or flush outside of the try/except that handle `KeyboardInterrupt` (which `error.SignalInterrupt` is a subclass of), then control will escape from the `dispatch` module. Let's fix that by ignoring errors from flushing the ui. I would have rather fixed this by restoring the stdout and stderr streams when the pager dies, but it gets complicated because of multiple ui instances (ui/lui) and different pager setups between regular hg and chg. This changes a test in `test-pager.t`, but I don't understand why. I would have thought that all the output from the command should have gone to the broken pager. Differential Revision: https://phab.mercurial-scm.org/D11627
-
Martin von Zweigbergk authored
If we already have a non-zero exit code, I don't think we should change it to 255 because we fail to flush stdio. This may not matter yet, but it will matter when I make a killed pager result in exit code 250 (it's currently 255). Differential Revision: https://phab.mercurial-scm.org/D11626
-
- Oct 11, 2021
-
-
Simon Sapin authored
The patch originally sent as https://phab.mercurial-scm.org/D11546 used "byte string" but that was changed during review to avoid suggesting Unicode or character encodings. However "byte range" sounds to be like a range of *indices* within a byte string/sequence elsewhere. This changes to "byte sequence". Python docs use "sequence" a lot when discussing the `bytes` type: https://docs.python.org/3/library/stdtypes.html Differential Revision: https://phab.mercurial-scm.org/D11623
-
- Oct 08, 2021
-
-
Simon Sapin authored
This default is used when running `cargo` manually such as for `cargo test`. `setup.py` and `Makefile` both configure the Python major version explicitly. Differential Revision: https://phab.mercurial-scm.org/D11618
-
- Oct 04, 2021
-
-
Matt Harbison authored
Not sure if this helps with recent certificate issues[1], but we might as well keep this modern. Note that certifi no longer claims py2 support, and there's a PR to add it back in[2]. Py2 support was dropped in 2020.04.05.2 (which predates what's being updated here). None of the *.py files have changed since the 2020.6.20 release, and I was able to call `certifi.where()` in both a virtualenv and with `hg debugshell` from an MSI install with this version, so we shouldn't be any worse off than before. [1] mercurial/tortoisehg/thg#5745 [2] https://github.com/certifi/python-certifi/pull/154 Differential Revision: https://phab.mercurial-scm.org/D11609
-
- Sep 19, 2021
-
-
Matt Harbison authored
Now that exewrapper is smart enough to find the DLLs it needs without help from the build script, backout ed286d150aa8 and 2960b7fac966. Note that this will require deleting the build/lib.win-amd64-3.X directory to actually remove it from the final wheel. Differential Revision: https://phab.mercurial-scm.org/D11455
-
Matt Harbison authored
Previously, we relied on the default library lookup[1], which for us is essentially to look on `PATH`. That has issues- the Python installations are not necessarily on `PATH`, so I started copying the DLLs locally in 2960b7fac966 and ed286d150aa8 during the build to work around that. However, it's been discovered that causes `python3.dll` and `python3X.dll` to get slipped into the wheel that gets distributed on PyPI. Additionally, Mercurial would fail to run in a venv if the Python environment that created it isn't on `PATH`, because venv creation doesn't copy the DLLs locally. The logic here is inspired by the `py.exe` launcher[2], though this is simpler because we don't care about the architecture- if this is a 32 bit process running on Win64, the registry reflection will redirect to where the 32 bit Python process wrote its keys. A nice unintended side effect is to also make venvs that don't have their root Python on `PATH` work without all of the code required to read `pyvenv.cfg`[3]. I don't see any reasonable way to create a venv without Python being installed (other than maybe building Python from source?), so punt on trying to read that file for now and save a bunch of string manipulation code. I somehow managed to corrupt my Windows user profile, and that makes the Microsoft Store python not run (even loading the DLL gives an access error), so I'm giving priority to both global and user specific python.org installations. Loading python3.dll is new, but when I went down the rabbit hole of implementing `pyvenv.cfg` support, I saw a comment[4] that led me to think we could have trouble if we don't. The comment in ed286d150aa8 confirms this, so we should probably bail out completely if Python3 can't be loaded from the registry, rather than getting something random on `PATH`. But I'll leave that for the default branch. [1] https://docs.microsoft.com/en-us/windows/win32/Dlls/dynamic-link-library-search-order#standard-search-order-for-desktop-applications [2] https://github.com/python/cpython/blob/adcd2205565f91c6719f4141ab4e1da6d7086126/PC/launcher.c#L249 [3] https://github.com/python/cpython/blob/bb3e0c240bc60fe08d332ff5955d54197f79751c/PC/getpathp.c#L707 [4] https://github.com/python/cpython/blob/bb3e0c240bc60fe08d332ff5955d54197f79751c/PC/getpathp.c#L1098 Differential Revision: https://phab.mercurial-scm.org/D11454
-
- Sep 02, 2021
-
-
Danny Hooper authored
By grouping together (path, ctx) pairs according to the inputs they would provide to fixer tools, we can deduplicate executions of fixer tools to significantly reduce the amount of time spent running slow tools. This change does not handle clean files in the working copy, which could still be deduplicated against the files in the checked out commit. It's a little harder to do that because the filerev is not available in the workingfilectx (and it doesn't exist for added files). Anecdotally, this change makes some real uses cases at Google 10x faster. I think we were originally hesitant to do this because the benefits weren't obvious, and implementing it efficiently is kind of tricky. If we simply memoized the formatter execution function, we would be keeping tons of file content in memory. Also included is a regression test for a corner case that I broke with my first attempt at optimizing this code. Differential Revision: https://phab.mercurial-scm.org/D11280
-
Danny Hooper authored
The current implementation wastes a lot of effort invoking fixer tools more than once on the same file name+content. It is good to track changes in this behavior. Differential Revision: https://phab.mercurial-scm.org/D11279
-
- Jun 25, 2021
-
-
Pulkit Goyal authored
Adds a very basic replica of `ui.plain()`. Differential Revision: https://phab.mercurial-scm.org/D10912
-
- Oct 05, 2021
-
-
Pulkit Goyal authored
Differential Revision: https://phab.mercurial-scm.org/D11614
-
Pulkit Goyal authored
Commands like `files`, `status` supports printing relative paths. Hence we need to re-use this code in other places too. So let's take this out from `rhg files` into a utility function. Next patch will make `rhg status` use it. Differential Revision: https://phab.mercurial-scm.org/D11613
-
- Oct 06, 2021
-
-
Sushil Khanchi authored
This change is to help extensions by not forcing them to populate with opts[b'bundle'] and opts[b'force'] when calling hg.incoming(...) Differential Revision: https://phab.mercurial-scm.org/D11619
-
- Oct 05, 2021
-
-
Arseniy Alekseyev authored
Also tweak the help for the anonymous argument. Differential Revision: https://phab.mercurial-scm.org/D11617
-
- Jun 24, 2021
-
-
Pulkit Goyal authored
`rhg status` is experimental right now and does not support all functionalities. While the long term target is to implement them, for now we add a fallback to have all tests pass with `rhg status` enabled. Differential Revision: https://phab.mercurial-scm.org/D10906
-
- Jul 18, 2021
-
-
Pulkit Goyal authored
Since the largefiles dirstate is now part of transaction, we get rid of this temporary fix which lived for ~7 years. Differential Revision: https://phab.mercurial-scm.org/D11612
-
Pulkit Goyal authored
This will help us in automatically restoring the largefilesdirstate if a transaction is rolled back. Differential Revision: https://phab.mercurial-scm.org/D11611
-
Pulkit Goyal authored
Right now, the largefile dirstate is not included in transaction which makes things complex. Next patch will add code to do so, so let's make it mandatory to pass current transaction and pass from all existing callers. Differential Revision: https://phab.mercurial-scm.org/D11610
-
- Oct 07, 2021
-
-
Augie Fackler authored
-
- Oct 05, 2021
-
-
Pulkit Goyal authored
-
Pulkit Goyal authored
-
- Oct 01, 2021
-
-
Simon Sapin authored
It can be viewed by running `hg help internals.dirstate-v2` Since that command rewraps paragraphs, the source text is written with semantic line breaks: https://sembr.org/ Differential Revision: https://phab.mercurial-scm.org/D11546
-
Simon Sapin authored
Having `data_size` next to `uuid_size` (and the UUID itself) makes more sense. Differential Revision: https://phab.mercurial-scm.org/D11545
-
Pierre-Yves David authored
Nobody is calling it anymore. Its purposes has been filled. Differential Revision: https://phab.mercurial-scm.org/D11608
-
Pierre-Yves David authored
The constructor is on its way out, so we inline the last relevant call before dropping it. Differential Revision: https://phab.mercurial-scm.org/D11607
-
Pierre-Yves David authored
The constructor is on its way out, so we inline a relevant call before dropping it. Differential Revision: https://phab.mercurial-scm.org/D11606
-
Pierre-Yves David authored
Nobody is calling it anymore. Its purposes has been filled. Differential Revision: https://phab.mercurial-scm.org/D11605
-
Pierre-Yves David authored
The constructor is on its way out, so we inline the last relevant call before dropping it. Differential Revision: https://phab.mercurial-scm.org/D11604
-
Pierre-Yves David authored
Nobody is calling it anymore. Its purposes has been filled. Differential Revision: https://phab.mercurial-scm.org/D11603
-
Pierre-Yves David authored
The constructor is on its way out, so we inline the last relevant call before dropping it. Differential Revision: https://phab.mercurial-scm.org/D11602
-