Matt Harbison <matt_harbison@yahoo.com> [Sun, 19 Sep 2021 01:23:16 -0400] rev 48191
exewrapper: find the proper python3X.dll in the registry
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
Danny Hooper <hooper@google.com> [Thu, 02 Sep 2021 14:08:45 -0700] rev 48190
fix: reduce number of tool executions
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 <hooper@google.com> [Thu, 02 Sep 2021 14:07:55 -0700] rev 48189
fix: add test to demonstrate how many times tools are executed
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
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 25 Jun 2021 15:00:08 +0530] rev 48188
rhg: add ui.plain() and check it before showing relative paths in status
Adds a very basic replica of `ui.plain()`.
Differential Revision: https://phab.mercurial-scm.org/D10912
Pulkit Goyal <7895pulkit@gmail.com> [Tue, 05 Oct 2021 18:10:04 +0530] rev 48187
rhg: add relative paths support in `rhg status`
Differential Revision: https://phab.mercurial-scm.org/D11614
Pulkit Goyal <7895pulkit@gmail.com> [Tue, 05 Oct 2021 18:02:22 +0530] rev 48186
rhg: refactor function to relativize paths in utils
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
Sushil khanchi <sushilkhanchi97@gmail.com> [Wed, 06 Oct 2021 13:32:07 +0530] rev 48185
hg: let extensions call the func without populating opts keys
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
Arseniy Alekseyev <aalekseyev@janestreet.com> [Tue, 05 Oct 2021 16:09:20 +0100] rev 48184
rhg: in rhg cat cli, fix the long name of the --rev flag
Also tweak the help for the anonymous argument.
Differential Revision: https://phab.mercurial-scm.org/D11617
Pulkit Goyal <7895pulkit@gmail.com> [Thu, 24 Jun 2021 14:23:11 +0530] rev 48183
rhg: fallback if tweakdefaults or statuscopies is enabled with status
`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
Pulkit Goyal <7895pulkit@gmail.com> [Mon, 19 Jul 2021 04:13:50 +0530] rev 48182
largefiles: partially undo 61e526585b20e2ff15f19497d0451d18fea02db8 and child
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 <7895pulkit@gmail.com> [Mon, 19 Jul 2021 04:12:14 +0530] rev 48181
largefiles: add tr backup for largefilesdirstate
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 <7895pulkit@gmail.com> [Mon, 19 Jul 2021 04:11:08 +0530] rev 48180
largefiles: pass current transaction to `lfdirstate.write()`
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
Augie Fackler <augie@google.com> [Thu, 07 Oct 2021 10:23:57 -0400] rev 48179
merge: with stable
Simon Sapin <simon.sapin@octobus.net> [Fri, 01 Oct 2021 12:17:09 +0200] rev 48178
dirstate-v2: Add internal documentation
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 <simon.sapin@octobus.net> [Fri, 01 Oct 2021 12:27:17 +0200] rev 48177
dirstate-v2: Move data file info in the docket closer together
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 <pierre-yves.david@octobus.net> [Fri, 01 Oct 2021 09:29:50 +0200] rev 48176
dirstate-item: drop the legacy new_normal constructor
Nobody is calling it anymore. Its purposes has been filled.
Differential Revision: https://phab.mercurial-scm.org/D11608
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 01 Oct 2021 09:29:32 +0200] rev 48175
dirstate-item: replace call to new_normal
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 <pierre-yves.david@octobus.net> [Fri, 01 Oct 2021 09:28:19 +0200] rev 48174
dirstate-item: replace a call to new_normal
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 <pierre-yves.david@octobus.net> [Fri, 01 Oct 2021 09:25:13 +0200] rev 48173
dirstate-item: drop the legacy new_possibly_dirty constructor
Nobody is calling it anymore. Its purposes has been filled.
Differential Revision: https://phab.mercurial-scm.org/D11605
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 01 Oct 2021 09:24:48 +0200] rev 48172
dirstate-item: replace call to new_possibly_dirty
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 <pierre-yves.david@octobus.net> [Fri, 01 Oct 2021 09:23:28 +0200] rev 48171
dirstate-item: drop the legacy new_from_p2 constructor
Nobody is calling it anymore. Its purposes has been filled.
Differential Revision: https://phab.mercurial-scm.org/D11603
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 01 Oct 2021 09:21:52 +0200] rev 48170
dirstate-item: replace call to new_from_p2
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
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 01 Oct 2021 09:16:53 +0200] rev 48169
dirstate-item: drop the legacy new_added constructor
Nobody is calling it anymore. Its purposes has been filled.
Differential Revision: https://phab.mercurial-scm.org/D11601
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 01 Oct 2021 09:15:03 +0200] rev 48168
dirstate-item: replace call to new_added
The constructor is on its way out, so we inline the last relevant call before
dropping it.
Differential Revision: https://phab.mercurial-scm.org/D11600
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 01 Oct 2021 09:14:10 +0200] rev 48167
dirstate-item: drop the legacy new_merged constructor
Nobody is calling it anymore. Its purposes has been filled.
Differential Revision: https://phab.mercurial-scm.org/D11599
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 01 Oct 2021 09:12:52 +0200] rev 48166
dirstate-item: replace call to new_merged
The constructor is on its way out, so we inline the last relevant call before
dropping it.
Differential Revision: https://phab.mercurial-scm.org/D11598
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 01 Oct 2021 03:30:00 +0200] rev 48165
dirstate-item: drop the `merged` property
It has no user anymore.
Differential Revision: https://phab.mercurial-scm.org/D11597
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 01 Oct 2021 03:29:33 +0200] rev 48164
dirstate-item: replace another usage of `merged`
We simply spell out the logic here. This was the last usage of `merged`.
Differential Revision: https://phab.mercurial-scm.org/D11596
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 01 Oct 2021 03:28:01 +0200] rev 48163
dirstate-item: replace a `merged` usage with `p2_info`
It seems more accurate and no test complains (XXX hopefully XXX).
Differential Revision: https://phab.mercurial-scm.org/D11595
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 01 Oct 2021 03:26:12 +0200] rev 48162
dirstate-item: drop the `from_p2` property
It has no user anymore.
Differential Revision: https://phab.mercurial-scm.org/D11594
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 01 Oct 2021 03:24:57 +0200] rev 48161
dirstate-item: directly use `p2_info` in `v1_size`
This is simpler.
Differential Revision: https://phab.mercurial-scm.org/D11593
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 01 Oct 2021 04:04:38 +0200] rev 48160
dirstate-item: use the `p2_info` property to replace more verbose call
Differential Revision: https://phab.mercurial-scm.org/D11592
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 29 Sep 2021 02:06:04 +0200] rev 48159
status: process `from_p2` file the same as `merged` one
What matters here is that the file constains information coming from the second
parent and should be considered `modified` on plain `hg status.
So we can process `from_p2` file sooner. It also highlight that we probably
don't need the merged/from_p2 distinction at higher level.
Differential Revision: https://phab.mercurial-scm.org/D11591
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 01 Oct 2021 02:43:39 +0200] rev 48158
dirstate: drop an incorrect comment
We are actually checking that we are only in a case were the file might needs
lookup before doing this. So the comment is not relevant.
Differential Revision: https://phab.mercurial-scm.org/D11590
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 01 Oct 2021 01:45:20 +0200] rev 48157
dirstate: drop some duplicated code
The same operation is done a handful a line lower.
Differential Revision: https://phab.mercurial-scm.org/D11589
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 30 Sep 2021 16:33:12 +0200] rev 48156
dirstate: align the dirstate's API to the lower level ones
This conclude the refactoring of this API. We can now finalize the dirstate v2
on disk format.
Differential Revision: https://phab.mercurial-scm.org/D11587
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 01 Oct 2021 04:07:21 +0200] rev 48155
dirstate-item: introduce a `p1_tracked` property
It is useful to simplify various conditional that use `any_tracked and not
added`.
Differential Revision: https://phab.mercurial-scm.org/D11586
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 01 Oct 2021 04:04:09 +0200] rev 48154
dirstate-item: introduce a `p2_info` property that combine two others
The `merged` and `from_p2` property are always used together so we can expose a
combined property instead.
Differential Revision: https://phab.mercurial-scm.org/D11585
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 01 Oct 2021 02:01:12 +0200] rev 48153
dirstate: narrow gathering of parent data
The parent data are only going to be useful is the file might be clean. And it
might only be clean if it is tracked in both p1 and the working copy.
Differential Revision: https://phab.mercurial-scm.org/D11584
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 01 Oct 2021 01:27:53 +0200] rev 48152
dirstate: align the dirstatemap's API to the data change
We are passing different data, so lets simplify the dirstatemap API too.
Differential Revision: https://phab.mercurial-scm.org/D11583
Simon Sapin <simon.sapin@octobus.net> [Fri, 01 Oct 2021 18:49:33 +0200] rev 48151
dirstate-v2: Store a bitfield on disk instead of v1-like state
Differential Revision: https://phab.mercurial-scm.org/D11558
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 01 Oct 2021 20:35:30 +0200] rev 48150
dirstate-item: change the internal storage and constructor value
This should be closer to what we do need and what we can actually reliably
record.
In practice it means that we abandon the prospect of storing much more refined
data for now. We don't have the necessary information nor code using it right
now. So it seems safer to just use a clearer version of what we had so far.
See the documentation changes for details.
Differential Revision: https://phab.mercurial-scm.org/D11557
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 02 Oct 2021 11:39:57 +0200] rev 48149
dirstatemap: drop legacy method on the dirstatemap wrapper
They are no longer in use now that the Rust wrapper version of the Dirstatemap
are back in line with the Python one.
Differential Revision: https://phab.mercurial-scm.org/D11582
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 02 Oct 2021 00:15:24 +0200] rev 48148
dirstatemap: align the Rust wrapper implementation of `setparent`
We move to using `drop_merge_data` as intended.
Differential Revision: https://phab.mercurial-scm.org/D11581
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 02 Oct 2021 00:44:17 +0200] rev 48147
dirstatemap: fix copymap.pop in Rust to return the value it pops
I guess this was overlooked in the initial implementation?
Without this, the next patch would, loose copy information in setparent.
Differential Revision: https://phab.mercurial-scm.org/D11580
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 02 Oct 2021 00:14:32 +0200] rev 48146
dirstate-item: implement `drop_merge_data` on the Rust DirstateItem
It was currently missing and we want to be able to use in it the Rust case too.
Differential Revision: https://phab.mercurial-scm.org/D11579
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 02 Oct 2021 00:02:55 +0200] rev 48145
dirstatemap: use a common implement for reset_state
Same logic as for `set_untracked` this make sure both implementation are aligned.
The `reset_state` implementation for the Rust wrapped had signicantly diverged,
this change finally put it back in line.
Differential Revision: https://phab.mercurial-scm.org/D11578
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 02 Oct 2021 00:01:56 +0200] rev 48144
dirstatemap: add a common `_drop_entry` method for dirstatemap
This method is called to remove DirstateItem from the map.
Each variant have a different implementation (which is … the point).
Differential Revision: https://phab.mercurial-scm.org/D11577
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 01 Oct 2021 23:49:40 +0200] rev 48143
dirstatemap: use common code for set_clean
Same logic before this make sure both implementation use the same logic for this.
Differential Revision: https://phab.mercurial-scm.org/D11576
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 01 Oct 2021 23:42:24 +0200] rev 48142
dirstatemap: use common code for set_possibly_dirty
Same logic before this make sure both implementation use the same logic for this.
Differential Revision: https://phab.mercurial-scm.org/D11575
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 01 Oct 2021 23:24:01 +0200] rev 48141
dirstatemap: use a common implement for set_tracked
Same logic as for `set_untracked` this make sure both implementation use the
same logic for this.
Differential Revision: https://phab.mercurial-scm.org/D11574
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 01 Oct 2021 23:13:44 +0200] rev 48140
dirstatemap: add a common `_insert_entry` method for dirstatemap
This method is called to add a new DirstateItem to the map.
Each variant have a different implementation (which is … the point).
Differential Revision: https://phab.mercurial-scm.org/D11573
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 01 Oct 2021 19:14:09 +0200] rev 48139
dirstatemap: use a common implementation for `dirstatemap.set_untracked`
We can now make sure they use the same code, and drop the older, out of sync,
implementation of `set_untracked` for the rust wrapper.
Differential Revision: https://phab.mercurial-scm.org/D11572
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 01 Oct 2021 18:54:40 +0200] rev 48138
dirstatemap: add a common `_refresh_entry` method for dirstatemap
This method is called once a DirstateItem have been modified to apply the
change on the dirstatemap if necessary.
Each variant have a different implementation (which is … the point).
We use `addfile` for the rustmap and not `set_dirstate_item` because we need to
keep the internal counter up to date and `set_dirstate_item` does not do it.
Differential Revision: https://phab.mercurial-scm.org/D11571
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 01 Oct 2021 18:52:26 +0200] rev 48137
dirstatemap: create `_dirs_incr/_dirs_decr` methods on the common class
The Rust wrapper does not need them. However having a default, no-op,
implementation will help use to write code used by both implementation.
Differential Revision: https://phab.mercurial-scm.org/D11570
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 01 Oct 2021 18:49:21 +0200] rev 48136
dirstatemap: small rework of the `set_untracked` method
This shuffle the code a bit to have it flowing more "naturally". This will help
us to create a common version of this code in the next changesets.
Differential Revision: https://phab.mercurial-scm.org/D11569
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 02 Oct 2021 12:10:46 +0200] rev 48135
dirstatemap: arrange methods by category
The dirstatemap code cover various aspects, it grow a bit messy over the years. So we shuffle the code around into some documented categories.
This will help use to clean up the code.
No code was changed in this changeset, only code move.
Differential Revision: https://phab.mercurial-scm.org/D11568
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 02 Oct 2021 12:01:50 +0200] rev 48134
dirstatemap: move a multiple simple functions in the common class
These are small and simple, lets factor them out.
Differential Revision: https://phab.mercurial-scm.org/D11567
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 01 Oct 2021 17:10:24 +0200] rev 48133
dirstatemap: rename `_rustmap` to `_map`
This match the name of the `map` for the other implementation and will make it
simpler to share code between the two.
Differential Revision: https://phab.mercurial-scm.org/D11566
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 01 Oct 2021 16:52:44 +0200] rev 48132
dirstatemap: use a common __init__ for dirstatemap
This is the first and simplest things to put in common.
Differential Revision: https://phab.mercurial-scm.org/D11565
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 01 Oct 2021 16:14:29 +0200] rev 48131
dirstatemap: introduce a common base for the dirstatemap class
We have two dirstatemaps class. One for the python version of the dirstate map
and one for the Rust version (that has a python wrapper to deal with some
aspect of it). We end up with duplicated code between them, so we introduce a
common base class to start migrating common code in them.
Differential Revision: https://phab.mercurial-scm.org/D11564
Martin von Zweigbergk <martinvonz@google.com> [Tue, 28 Sep 2021 15:11:22 -0700] rev 48130
errors: raise InputError from revsingle() iff revset provided by the user
Same reasoning as for `revrange()` in an earlier patch.
Differential Revision: https://phab.mercurial-scm.org/D11562
Martin von Zweigbergk <martinvonz@google.com> [Tue, 28 Sep 2021 13:59:01 -0700] rev 48129
errors: raise InputError from revpair() iff revset provided by the user
Same reasoning as for `revrange()` in an earlier patch.
Differential Revision: https://phab.mercurial-scm.org/D11561
Martin von Zweigbergk <martinvonz@google.com> [Tue, 28 Sep 2021 08:47:11 -0700] rev 48128
errors: raise InputError on bad revset to revrange() iff provided by the user
Most callers of `scmutil.revrange()` pass in a revset provided by the
user. If there are problems resolving that, it should result in an
`InputError` and exit code 10 (when using detailed exit
codes). However, there are also some callers that pass in revsets not
provided by the user. `InputError` is not appropriate in those
cases. This patch therefore introduces a wrapper around
`scmutil.revrange()` that simply converts the exception type. I put it
in `logcmdutil.py` since that seems to be the lowest-level module in
the (poorly defined) UI layer.
Differential Revision: https://phab.mercurial-scm.org/D11560