- Feb 10, 2021
-
-
Pierre-Yves David authored
The change is quite new and undocumented (since it is experimental) so it seems premature to make it available in tweak default. In addition, I am not sure the new return code are frozen yet (eg: some of the initial feedback have not been incorporated). Before the release I doubled check (probably with Martin) that they were not enabled by default and got replied that they were only enabled in the tests. Have I been aware that they have been also enabled in tweak default I would I have lobbied to delay that. I discovered they were in tweak default from users feedback. They found it an unpleasant and unexpected surprise of 5.7. So I suggest we no enable enable this experimental feature for Mercurial 5.7 and revisit this later, when the feature will be more mature. Differential Revision: https://phab.mercurial-scm.org/D9975
-
- Feb 09, 2021
-
-
Pierre-Yves David authored
The change is missing a the `b'foo'` prefix to make it a bytestring. This lead to a traceback in some third party extension. It is unclear to me why the Mercurial test pass without it. Differential Revision: https://phab.mercurial-scm.org/D9974
-
- Jan 18, 2021
-
-
Pierre-Yves David authored
The `debug` namespace is not intended for end user and advertising it is a path to confusion and trouble. I think we should wait for the `admin` namespace to exists and the command to be available as `admin--strip` before we advertise it. Differential Revision: https://phab.mercurial-scm.org/D9817
-
- Feb 04, 2021
-
-
Jordi Gutiérrez Hermoso authored
The url.open function has acquired a lot of kwargs over the years. When running `hg import http://example.com/hg/diff/1`, since at least a708e1e4d7a8 in March, 2018, the calling sites for url.open try to pass a `sendaccept` parameter that largefiles' override doesn't accept. Currently that stack traces something like this: Traceback (most recent call last): File "/tmp/hgtests.sv744r5t/install/bin/hg", line 59, in <module> dispatch.run() File "/tmp/hgtests.sv744r5t/install/lib/python/mercurial/dispatch.py", line 143, in run status = dispatch(req) File "/tmp/hgtests.sv744r5t/install/lib/python/mercurial/dispatch.py", line 245, in dispatch status = _rundispatch(req) File "/tmp/hgtests.sv744r5t/install/lib/python/mercurial/dispatch.py", line 289, in _rundispatch ret = _runcatch(req) or 0 File "/tmp/hgtests.sv744r5t/install/lib/python/mercurial/dispatch.py", line 465, in _runcatch return _callcatch(ui, _runcatchfunc) File "/tmp/hgtests.sv744r5t/install/lib/python/mercurial/dispatch.py", line 475, in _callcatch return scmutil.callcatch(ui, func) File "/tmp/hgtests.sv744r5t/install/lib/python/mercurial/scmutil.py", line 155, in callcatch return func() File "/tmp/hgtests.sv744r5t/install/lib/python/mercurial/dispatch.py", line 455, in _runcatchfunc return _dispatch(req) File "/tmp/hgtests.sv744r5t/install/lib/python/mercurial/dispatch.py", line 1259, in _dispatch lui, repo, cmd, fullargs, ui, options, d, cmdpats, cmdoptions File "/tmp/hgtests.sv744r5t/install/lib/python/mercurial/dispatch.py", line 913, in runcommand ret = _runcommand(ui, options, cmd, d) File "/tmp/hgtests.sv744r5t/install/lib/python/mercurial/dispatch.py", line 1270, in _runcommand return cmdfunc() File "/tmp/hgtests.sv744r5t/install/lib/python/mercurial/dispatch.py", line 1256, in <lambda> d = lambda: util.checksignature(func)(ui, *args, **strcmdopt) File "/tmp/hgtests.sv744r5t/install/lib/python/mercurial/util.py", line 1867, in check return func(*args, **kwargs) File "/tmp/hgtests.sv744r5t/install/lib/python/mercurial/commands.py", line 4184, in import_ patchfile = hg.openpath(ui, patchurl, sendaccept=False) File "/tmp/hgtests.sv744r5t/install/lib/python/mercurial/hg.py", line 181, in openpath return url.open(ui, path, sendaccept=sendaccept) TypeError: openlargefile() got an unexpected keyword argument 'sendaccept' So, just accept and pass along any kwargs of the overridden function.
-
Yuya Nishihara authored
-
- Feb 02, 2021
-
-
Pulkit Goyal authored
-
Pulkit Goyal authored
-
- Jan 29, 2021
-
-
Martin von Zweigbergk authored
The same procedure as every year^Wcycle. Differential Revision: https://phab.mercurial-scm.org/D9909
-
- Feb 01, 2021
-
-
Matt Harbison authored
Differential Revision: https://phab.mercurial-scm.org/D9943
-
Matt Harbison authored
Sadly, there's not `python3.exe` on Windows. Differential Revision: https://phab.mercurial-scm.org/D9937
-
- Jan 27, 2021
-
-
Kyle Lippincott authored
This is to fix an issue we've noticed where fresh installations start at `C:\Program Files\Mercurial`, and then upgrades "walk up" the tree and end up in `C:\Program Files` and finally `C:\` (where they stay). ComponentSearch defaults to finding files, which I think means "it produces a string like `C:\Program Files\Mercurial`", whereas with the type being explicitly a directory, it would return `C:\Program Files\Mercurial\` (note the final trailing backslash). Presumably, a latter step then tries to turn that file name into a proper directory, by removing everything after the last `\`. This could likely also be fixed by actually searching for the component for hg.exe itself. That seemed a lot more complicated, as the GUID for hg.exe isn't known in this file (it's one of the "auto-derived" ones). We could also consider adding a Condition that I think could check the Property and ensure it's either empty or ends in a trailing slash, but that would be an installer runtime check and I'm not convinced it'd actually be useful. This will *not* cause existing installations that are in one of the bad directories to fix themselves. Doing that would require a fair amount more understanding of wix and windows installer than I have, and it *probably* wouldn't be possible to be 100% correct about it either (there's nothing preventing a user from intentionally installing it in C:\, though I don't know why they would do so). If someone wants to tackle fixing existing installations, I think that the first installation is actually the only one that shows up in "Add or Remove Programs", and that its registry keys still exist. You might be able to find something under HKEY_USERS that lists both the "good" and the "bad" InstallDirs. Mine was under `HKEY_USERS\S-1-5-18\Software\Mercurial\InstallDir` (C:\), and `HKEY_USERS\S-1-5-21-..numbers..\Software\Mercurial\InstallDir` (C:\Program Files\Mercurial). If you find exactly two, with one being the default path, and the other being a prefix of it, the user almost certainly hit this bug :D We had originally thought that this bug might be due to unattended installations/upgrades, but I no longer think that's the case. We were able to reproduce the issue by uninstalling all copies of Mercurial I could find, installing one version (it chose the correct location), and then starting the installer for a different version (higher or lower didn't matter). I did not need to deal with an unattended or headless installation/upgrade to trigger the issue, but it's possible that my system was "primed" for this bug to happen because of a previous unattended installation/upgrade. Differential Revision: https://phab.mercurial-scm.org/D9891
-
Matt Harbison authored
Differential Revision: https://phab.mercurial-scm.org/D9885
-
- Jan 28, 2021
-
-
Simon Sapin authored
Use Rust’s `libc::ssize_t` as the closest match to C’s `Py_ssize_t`. See details in test comment. Going forward we should find a way to have such Rust declarations auto-generated from C headers at build time, or auto-checked against them in a test. Differential Revision: https://phab.mercurial-scm.org/D9901
-
Simon Sapin authored
Thanks to Mitchell Plamann for reporting this bug. The next commit fixes it. Differential Revision: https://phab.mercurial-scm.org/D9900
-
- Jan 25, 2021
-
-
Matt Harbison authored
The `_curses.pyd` module was previously being included by py2exe's module search, but it left out `_curses_panel.pyd`. Differential Revision: https://phab.mercurial-scm.org/D9857
-
Matt Harbison authored
Maybe this was missing because there wasn't a need for it. Differential Revision: https://phab.mercurial-scm.org/D9856
-
Gregory Szorc authored
This is necessary to work around a bug that caused build failures on current stable with 0.9.0. This patch was used to build the 5.7rc0 Windows installers. Differential Revision: https://phab.mercurial-scm.org/D9858
-
- Jan 08, 2021
-
-
Raphaël Gomès authored
This is just wasteful for all steps that do not use Rust. Differential Revision: https://phab.mercurial-scm.org/D9717
-
- Jan 22, 2021
-
-
Matt Harbison authored
Differential Revision: https://phab.mercurial-scm.org/D9851
-
Matt Harbison authored
Differential Revision: https://phab.mercurial-scm.org/D9850
-
Matt Harbison authored
I can't tell if we should leave the experimental one around for historical documentation purposes, but I'm not sure if there's value to doing that. Differential Revision: https://phab.mercurial-scm.org/D9849
-
- Jan 20, 2021
-
-
Pierre-Yves David authored
This should help user in trouble to find solution in the documentation. Differential Revision: https://phab.mercurial-scm.org/D9841
-
Pierre-Yves David authored
User should be able to find their way with that. Differential Revision: https://phab.mercurial-scm.org/D9840
-
Pierre-Yves David authored
The associated behavior is now clearer and we point to the other configuration that control the mismatching behavior. Differential Revision: https://phab.mercurial-scm.org/D9839
-
Pierre-Yves David authored
The feature is no longer experimental. Differential Revision: https://phab.mercurial-scm.org/D9838
-
Pierre-Yves David authored
The documentation for the option is now right after its parent configuration: `share.safe-mismatch.source-safe` Differential Revision: https://phab.mercurial-scm.org/D9837
-
Matt Harbison authored
The mode of failure here differs between `lfs-test-server` and `hg serve`, and they each throw a different exception. The `hg serve` case raises a subclass of `StorageError`, which gets a detailed status. The `lfs-test-server` case raises a subclass of `Abort`, which does not. Since the exit code isn't currently conditionizable in the tests, this is the simplest way to avoid the failure. Differential Revision: https://phab.mercurial-scm.org/D9836
-
Jörg Sonnenberger authored
Differential Revision: https://phab.mercurial-scm.org/D9842
-
- Jan 19, 2021
-
-
Pulkit Goyal authored
-
Pulkit Goyal authored
-
- Jan 18, 2021
-
-
Pulkit Goyal authored
The share-safe functionality is complete and all configuration options are implemented. The behavior is well discussed on mailing list and in reviews. Let's unmark this as experimental to solve a chichen and egg issue. Differential Revision: https://phab.mercurial-scm.org/D9823
-
- Jan 15, 2021
-
-
Pulkit Goyal authored
Config introduced in previous patch was `share.source-safe-mismatch`. Let's rename the warn as `share.source-safe-mismatch.warn`. While we are here, made sure we have different configs for upgrade and downgrade. Differential Revision: https://phab.mercurial-scm.org/D9786
-
- Jan 18, 2021
-
-
Pulkit Goyal authored
Recently I implemented various boolean configs which control how to behave when there is a share-safe mismatch between source and share repository. Mismatch means that source supports share-safe where as share does not or vice versa. However, while discussion and documentation we realized that it's too complicated and there are some combinations of values which makes no sense. We decided to introduce a config option with 4 possible values which makes controlling and understanding things easier. The config option `share.safe-mismatch.source-{not-}safe` can have following 4 values: * abort (default): error out if there is mismatch * allow: allow to work with respecting share source configuration * {up|down}grade-abort: try to {up|down}grade, if it fails, abort * {up|down}grade-allow: try to {up|down}grade, if it fails, continue in allow mode I am not sure if I can explain 3 config options which I deleted right now in just 5 lines which is a sign of how complex they became. No test changes demonstrate that functionality is same, only names have changed. Differential Revision: https://phab.mercurial-scm.org/D9785
-
- Jan 14, 2021
-
-
Pulkit Goyal authored
Earlier we used to allow shares which don't use share-safe mechanism to access repository which uses share-safe mechanism. This defeats the purpose and is bad behavior. This patch disallows that. Next patch will introduce a config option to allow that and have clearer understanding around various options. Differential Revision: https://phab.mercurial-scm.org/D9784
-
- Jan 18, 2021
-
-
Pulkit Goyal authored
Since we are writing to repository, it's better to re-read after taking the lock. Differential Revision: https://phab.mercurial-scm.org/D9822
-
- Jan 14, 2021
-
-
Pulkit Goyal authored
The final config calculation code does not require a lock, only writing it back does require one. Differential Revision: https://phab.mercurial-scm.org/D9783
-
- Jan 18, 2021
-
-
Pierre-Yves David authored
The bad order was introduced in d0225a22040c. Differential Revision: https://phab.mercurial-scm.org/D9829
-
Matt Harbison authored
I'm not sure why this only happens with py3, but this error code doesn't map to any of the 3 currently being handled, and kills `run-tests.py` before it can run any tests when it happens: OSError: [WinError 10013] An attempt was made to access a socket in a way forbidden by its access permissions The documentation[1] says this can happen if another process is bound to the address with exclusive access. This seems to keep it happy. [1] https://docs.microsoft.com/en-us/windows/win32/winsock/windows-sockets-error-codes-2 Differential Revision: https://phab.mercurial-scm.org/D9816
-
Matt Harbison authored
Windows doesn't have a `python3` executable, so cc0b332ab9fc attempted to work around the issue by copying the current python to `python3.exe`. That put it in `_tmpbindir` because of failures in `test-run-tests.t` when using `_bindir`, which looked like a process was trying to open it to write out a copy while it was in use. (Interestingly, I couldn't reproduce this running the test by itself in a loop for a couple of hours, but it happens constantly when running all tests.) The problem with using `_tmpbindir` is that it is the randomly generated path for the test run, and instead of Windows Firewall remembering the executable signature or image hash when allowing the process to open a server port, it apparently remembers the image path. That means every run will trigger a popup to allow it, which is bad for firing off a test run and walking away. I tried to symlink to the python executable, but that currently requires admin priviledges[1]. This will prompt the first time if the underlying python binary has never opened a server port, but appears to avoid it on subsequent runs. [1] https://bugs.python.org/issue40687 Differential Revision: https://phab.mercurial-scm.org/D9815
-