Sat, 01 Feb 2020 00:32:46 -0500 packaging: move the version normalization function to the util module stable
Matt Harbison <matt_harbison@yahoo.com> [Sat, 01 Feb 2020 00:32:46 -0500] rev 44220
packaging: move the version normalization function to the util module This will be used with Inno as well. Since this module isn't platform specific, rename to include that this is meant for Windows. (Mac has a different format.) Differential Revision: https://phab.mercurial-scm.org/D8059
Fri, 31 Jan 2020 22:20:39 -0500 resourceutil: account for the non-resource-like file hierarchy under py2exe stable
Matt Harbison <matt_harbison@yahoo.com> [Fri, 31 Jan 2020 22:20:39 -0500] rev 44219
resourceutil: account for the non-resource-like file hierarchy under py2exe After 9e367157a990, config files for py2exe were expected to be in C:\Program Files\Mercurial\mercurial\defaultrc because of the implied resource structure of 'mercurial.defaultrc.*.rc', relative to the executable. Accomodating this would require changes to the WIX and Inno scripts (and perhaps the script that generates the WIX script), as well as 3rd party bundlers like TortoiseHg. But these files aren't read as resources anyway- they fall back to the filesystem APIs. (If we really wanted to carry on the charade, the installer would have to also sprinkle various empty __init__.py files around.) Instead, this simply prunes the 'mercurial.' portion of the resource name when run with py2exe. (PyOxidizer uses the resources API, not the filesystem fallback, so it is unaffected.) Since this hack only affects the py2 Windows installers and is less risky, I think it's reasonable. We haven't needed to load any 3rd party resource up to this point, and would have to make packaging changes anyway to handle that. Differential Revision: https://phab.mercurial-scm.org/D8058
Thu, 30 Jan 2020 19:37:06 -0500 wix: restore COPYING.rtf stable
Matt Harbison <matt_harbison@yahoo.com> [Thu, 30 Jan 2020 19:37:06 -0500] rev 44218
wix: restore COPYING.rtf This got truncated to 0 bytes in 0ab651b5f77c when the Phabricator extension crashed because it's a binary file. That caused the license page in the WIX installer to be empty. I don't remember if I needed to resubmit after the bug was fixed, so let's try this again with the current stable. If this fails, I'll retry with 5.1 to see if this is a regression in the API changeover last cycle. Differential Revision: https://phab.mercurial-scm.org/D8052
Fri, 24 Jan 2020 12:50:27 +0100 contrib: a small script to nudge lingering diff
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 24 Jan 2020 12:50:27 +0100] rev 44217
contrib: a small script to nudge lingering diff After a discussion on IRC with various reviewers. It seems like a good idea to have some automatic cleanup of old, inactive diffs. Here is a small script able to do so. I am preparing to unleash it on our phabricator instance.
Sun, 26 Jan 2020 16:23:57 -0800 packaging: add support for PyOxidizer
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 26 Jan 2020 16:23:57 -0800] rev 44216
packaging: add support for PyOxidizer I've successfully built Mercurial on the development tip of PyOxidizer on Linux and Windows. It mostly "just works" on Linux. Windows is a bit more finicky. In-memory resource files are probably not all working correctly due to bugs in PyOxidizer's naming of modules. PyOxidizer now now supports installing files next to the produced binary. (We do this for templates in the added file.) So a workaround should be available. Also, since the last time I submitted support for PyOxidizer, PyOxidizer gained the ability to auto-generate Rust projects to build executables. So we don't need to worry about vendoring any Rust code to initially support PyOxidizer. However, at some point we will likely want to write our own command line driver that embeds a Python interpreter via PyOxidizer so we can run Rust code outside the confines of a Python interpreter. But that will be a follow-up. I would also like to add packaging.py CLI commands to build PyOxidizer distributions. This can come later, if ever. PyOxidizer's new "targets" feature makes it really easy to define packaging tasks in its Starlark configuration file. While not much is implemented yet, eventually we should be able to produce MSIs, etc using a `pyoxidizer build` one-liner. We'll get there... Differential Revision: https://phab.mercurial-scm.org/D7450
Wed, 29 Jan 2020 11:30:16 -0800 mergestate: add accessors for local and other nodeid, not just contexts
Martin von Zweigbergk <martinvonz@google.com> [Wed, 29 Jan 2020 11:30:16 -0800] rev 44215
mergestate: add accessors for local and other nodeid, not just contexts The mergestate can contain invalid nodeids. In that case, `mergestate.localctx` or `mergestate.otherctx` will fail. This patch provides a way of accessing the nodeid without failing in such cases. Differential Revision: https://phab.mercurial-scm.org/D8040
Wed, 15 Jan 2020 22:24:16 -0800 rebase: define base in only place in defineparents()
Martin von Zweigbergk <martinvonz@google.com> [Wed, 15 Jan 2020 22:24:16 -0800] rev 44214
rebase: define base in only place in defineparents() Just a little refactoring to prepare for the next patch. Differential Revision: https://phab.mercurial-scm.org/D7906
Fri, 20 Dec 2019 16:16:57 -0800 tests: use full `uncommit` command name in tests
Martin von Zweigbergk <martinvonz@google.com> [Fri, 20 Dec 2019 16:16:57 -0800] rev 44213
tests: use full `uncommit` command name in tests I'm about to add a `hg uncopy`, so the `hg unc` we used for `hg uncommit` would become ambiguous. Differential Revision: https://phab.mercurial-scm.org/D8028
Tue, 28 Jan 2020 14:53:23 -0800 graft: default `base` argument to common case of `ctx.p1()`
Martin von Zweigbergk <martinvonz@google.com> [Tue, 28 Jan 2020 14:53:23 -0800] rev 44212
graft: default `base` argument to common case of `ctx.p1()` I also updated the callers that wanted that, partly to simplify and partly to show that it works. Differential Revision: https://phab.mercurial-scm.org/D8027
Fri, 10 Jan 2020 13:12:24 -0800 graft: let caller pass in overlayworkingctx to merge.graft()
Martin von Zweigbergk <martinvonz@google.com> [Fri, 10 Jan 2020 13:12:24 -0800] rev 44211
graft: let caller pass in overlayworkingctx to merge.graft() Passing in a different `wctx` than `repo[None]` is useful because it allows the caller to decide to not touch the working directory. Differential Revision: https://phab.mercurial-scm.org/D8026
Wed, 29 Jan 2020 23:14:31 -0800 copies: fix crash when copy source is not in graft base
Martin von Zweigbergk <martinvonz@google.com> [Wed, 29 Jan 2020 23:14:31 -0800] rev 44210
copies: fix crash when copy source is not in graft base Differential Revision: https://phab.mercurial-scm.org/D8046
Wed, 29 Jan 2020 23:05:02 -0800 tests: add test showing crash when shelving ghosted rename target
Martin von Zweigbergk <martinvonz@google.com> [Wed, 29 Jan 2020 23:05:02 -0800] rev 44209
tests: add test showing crash when shelving ghosted rename target When you `hg rename` a file and then delete the rename target, `hg shelve` will give you a traceback. Note that the shelve succeeds and the shelve is correct, it's just the update to the parent that fails (i.e. to the parent of the commit that was created for the shelve). This can be squashed into the next commit if the reviewer prefers. Differential Revision: https://phab.mercurial-scm.org/D8045
Thu, 30 Jan 2020 23:48:45 -0500 resourceutil: correct the root path for file based lookup under py2exe stable
Matt Harbison <matt_harbison@yahoo.com> [Thu, 30 Jan 2020 23:48:45 -0500] rev 44208
resourceutil: correct the root path for file based lookup under py2exe This silly copy/paste error caused "Mercurial" to be truncated from "C:\Program Files". The fact that "helptext" and "defaultrc" are now in a subpackage of "mercurial" added it back on, and everything seemed to work. But that broke if not installed to the default directory, and also caused TortoiseHg to look at Mercurial's config files instead of its own. Differential Revision: https://phab.mercurial-scm.org/D8054
Tue, 22 Oct 2019 16:04:34 +0900 rust-cpython: mark all PyLeaked methods as unsafe
Yuya Nishihara <yuya@tcha.org> [Tue, 22 Oct 2019 16:04:34 +0900] rev 44207
rust-cpython: mark all PyLeaked methods as unsafe Unfortunately, these methods can be abused to obtain the inner 'static reference. The simplest (pseudo-code) example is: let leaked: PyLeaked<&'static _> = shared.leak_immutable(); let static_ref: &'static _ = &*leaked.try_borrow(py)?; // PyLeakedRef::deref() tries to bound the lifetime to itself, but // the underlying data is a &'static reference, so the returned // reference can be &'static. This problem can be easily fixed by coercing the lifetime, but there are many other ways to achieve that, and there wouldn't be a generic solution: let leaked: PyLeaked<&'static [_]> = shared.leak_immutable(); let leaked_iter: PyLeaked<slice::Iter<'static, _>> = unsafe { leaked.map(|v| v.iter()) }; let static_slice: &'static [_] = leaked_iter.try_borrow(py)?.as_slice(); So basically I failed to design the safe borrowing interface. Maybe we'll instead have to add much more restricted interface on top of the unsafe PyLeaked methods? For instance, Iterator::next() could be implemented if its Item type is not &'a (where 'a may be cheated.) Anyway, this seems not an easy issue, so it's probably better to leave the current interface as unsafe, and get broader comments while upstreaming this feature.
Sat, 19 Oct 2019 17:01:28 +0900 rust-cpython: make PySharedRef::try_borrow_mut() return BorrowMutError
Yuya Nishihara <yuya@tcha.org> [Sat, 19 Oct 2019 17:01:28 +0900] rev 44206
rust-cpython: make PySharedRef::try_borrow_mut() return BorrowMutError As I said, it shouldn't be an error of Python layer, but is something like a coding error. Returning BorrowMutError makes more sense. There's a weird hack to propagate the borrow-by-leaked state to RefCell to obtain BorrowMutError. If we don't like it, maybe we can add our own BorrowMutError.
Sat, 19 Oct 2019 16:48:34 +0900 rust-cpython: inline PySharedState::leak_immutable() and PyLeaked::new()
Yuya Nishihara <yuya@tcha.org> [Sat, 19 Oct 2019 16:48:34 +0900] rev 44205
rust-cpython: inline PySharedState::leak_immutable() and PyLeaked::new() For the same reason as the previous patch. The unsafe stuff can be better documented if these functions are inlined.
Sat, 19 Oct 2019 16:34:02 +0900 rust-cpython: inline PySharedState::try_borrow_mut()
Yuya Nishihara <yuya@tcha.org> [Sat, 19 Oct 2019 16:34:02 +0900] rev 44204
rust-cpython: inline PySharedState::try_borrow_mut() Since the core borrowing/leaking logic has been moved to PySharedRef* and PyLeaked*, it doesn't make sense that PySharedState had a function named "try_borrow_mut". Let's turn it into a pure data struct.
Sat, 12 Oct 2019 23:34:05 +0900 rust-cpython: add panicking version of borrow_mut() and use it
Yuya Nishihara <yuya@tcha.org> [Sat, 12 Oct 2019 23:34:05 +0900] rev 44203
rust-cpython: add panicking version of borrow_mut() and use it The original borrow_mut() is renamed to try_borrow_mut(). Since leak_immutable() no longer incref the borrow count, the caller should know if the underlying value is borrowed or not. No Python world is involved. That's why we can simply use the panicking borrow_mut().
Tue, 28 Jan 2020 22:27:30 -0500 setup: don't skip the search for global hg.exe if there is no local instance
Matt Harbison <matt_harbison@yahoo.com> [Tue, 28 Jan 2020 22:27:30 -0500] rev 44202
setup: don't skip the search for global hg.exe if there is no local instance The point of trying not to blindly execute `hg` on Windows is that the local hg.exe would be given precedence, and if py3 isn't on PATH, it errors out with a modal dialog. But that's not a problem if there is no local executable that could be run. The problem that I recently ran into was I upgraded the repo format to use zstd. But doing a `make clean` deletes all of the supporting libraries, causing the next run to abort with a message about not understanding the `revlog-compression-zstd` requirement. By getting rid of the local executable in the previous commit when cleaning, we avoid leaving a broken executable around, and avoid the py3 PATH problem too. There is still a small hole in that `hg.exe` needs to be deleted before switching between py2/py3/PyOxidizer builds, because the zstd module won't load. But that seems like good hygiene anyway. Differential Revision: https://phab.mercurial-scm.org/D8038
Tue, 28 Jan 2020 22:35:08 -0500 make: also delete hg.exe when cleaning
Matt Harbison <matt_harbison@yahoo.com> [Tue, 28 Jan 2020 22:35:08 -0500] rev 44201
make: also delete hg.exe when cleaning This will be needed for the next patch, which has more details. It has to come before the call into setup.py because even `python setup.py clean` calls hg to generate the version file. Differential Revision: https://phab.mercurial-scm.org/D8037
Thu, 23 Jan 2020 15:44:30 -0800 merge: start using the per-side copy dicts
Martin von Zweigbergk <martinvonz@google.com> [Thu, 23 Jan 2020 15:44:30 -0800] rev 44200
merge: start using the per-side copy dicts The point of this patch is mostly to clarify `manifestmerge()`. I find it much easier to reason about now. Differential Revision: https://phab.mercurial-scm.org/D7990
Wed, 22 Jan 2020 14:35:30 -0800 copies: define a type to return from mergecopies()
Martin von Zweigbergk <martinvonz@google.com> [Wed, 22 Jan 2020 14:35:30 -0800] rev 44199
copies: define a type to return from mergecopies() We'll soon return two instances of many of the dicts from `copies.mergecopies()`. That will mean that we need to return 9 different dicts, which is clearly not manageable. This patch instead encapsulates the 4 dicts we'll duplicate in a new type. For now, we still just return one instance of it (plus the separate `diverge` dict). Differential Revision: https://phab.mercurial-scm.org/D7989
Wed, 22 Jan 2020 16:45:56 -0800 merge: move initialization of copy dicts to one place
Martin von Zweigbergk <martinvonz@google.com> [Wed, 22 Jan 2020 16:45:56 -0800] rev 44198
merge: move initialization of copy dicts to one place Differential Revision: https://phab.mercurial-scm.org/D7988
Fri, 24 Jan 2020 10:39:55 -0800 copies: print debug information about copies per side/branch
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Jan 2020 10:39:55 -0800] rev 44197
copies: print debug information about copies per side/branch Differential Revision: https://phab.mercurial-scm.org/D7987
Wed, 22 Jan 2020 15:31:17 -0800 copies: make mergecopies() distinguish between copies on each side
Martin von Zweigbergk <martinvonz@google.com> [Wed, 22 Jan 2020 15:31:17 -0800] rev 44196
copies: make mergecopies() distinguish between copies on each side I find it confusing that most of the dicts returned from `mergecopies()` have entries specific to one branch of the merge, but they're still combined into dict. For example, you can't tell if `copy = {"bar": "foo"}` means that "foo" was copied to "bar" on the first branch or the second. It also feels like there are bugs lurking here because we may mistake which side the copy happened on. However, for most of the dicts, it's not possible that there is disagreement. For example, `renamedelete` keeps track of renames that happened on one side of the merge where the other side deleted the file. There can't be a disagreement there (because we record that in the `diverge` dict instead). For regular copies/renames, there can be a disagreement. Let's say file "foo" was copied to "bar" on one branch and file "baz" was copied to "bar" on the other. Beacause we only return one `copy` dict, we end up replacing the `{"bar": "foo"}` entry by `{"bar": "baz"}`. The merge code (`manifestmerge()`) will then decide that that means "both renamed from 'baz'". We should probably treat it as a conflict instead. The next few patches will make `mergecopies()` return two instances of most of the returned copies. That will lead to a bit more code (~40 lines), but I think it makes both `copies.mergecopies()` and `merge.manifestmerge()` clearer. Differential Revision: https://phab.mercurial-scm.org/D7986
Fri, 24 Jan 2020 17:25:40 -0800 pathutil: mark parent directories as audited as we go
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Jan 2020 17:25:40 -0800] rev 44195
pathutil: mark parent directories as audited as we go Before 0b7ce0b16d8a (pathauditor: change parts verification order to be root first, 2016-02-11), we used to validate child directories before parents. It was then important to only mark the child audited only after we had audited its parent (ancestors). I'm pretty sure we don't need to do that any more, now that we audit parents before children. Differential Revision: https://phab.mercurial-scm.org/D8002
Mon, 27 Jan 2020 09:14:19 -0800 cmdutil: change check_incompatible_arguments() *arg to single iterable
Martin von Zweigbergk <martinvonz@google.com> [Mon, 27 Jan 2020 09:14:19 -0800] rev 44194
cmdutil: change check_incompatible_arguments() *arg to single iterable This makes it clearer on the call-sites that the first argument is special. Thanks to Yuya for the suggestion. Differential Revision: https://phab.mercurial-scm.org/D8018
Mon, 27 Jan 2020 12:38:59 -0800 rust: remove an unnecessary set of parentheses
Martin von Zweigbergk <martinvonz@google.com> [Mon, 27 Jan 2020 12:38:59 -0800] rev 44193
rust: remove an unnecessary set of parentheses My build complained about this. I guess it started after I upgraded rustc. Differential Revision: https://phab.mercurial-scm.org/D8020
Mon, 27 Jan 2020 18:16:05 -0800 profiling: flush stdout before writing profile to stderr
Kyle Lippincott <spectral@google.com> [Mon, 27 Jan 2020 18:16:05 -0800] rev 44192
profiling: flush stdout before writing profile to stderr On py3, stdout and stderr appear to be buffered and this causes my command's output to be intermixed with the profiling output. Differential Revision: https://phab.mercurial-scm.org/D8024
Tue, 28 Jan 2020 10:40:19 -0800 rust: re-format with nightly rustfmt
Martin von Zweigbergk <martinvonz@google.com> [Tue, 28 Jan 2020 10:40:19 -0800] rev 44191
rust: re-format with nightly rustfmt This fixes test-check-rust-format.t. Differential Revision: https://phab.mercurial-scm.org/D8025
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 tip