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

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

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

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

merge: move initialization of copy dicts to one place Differential Revision: https://phab.mercurial-scm.org/D7988

copies: print debug information about copies per side/branch Differential Revision: https://phab.mercurial-scm.org/D7987

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