- Apr 24, 2020
-
-
Gregory Szorc authored
The time has come to support Python 3 on Windows. Let's teach our automation code to produce Windows wheels for Python 3.7 and 3.8. We could theoretically support 3.5 and 3.6. But I don't think it is worth it. People on Windows generally use the Mercurial installers, not wheels. And I'd prefer we limit variability and not have to worry about supporting earlier Python versions if it can be helped. As part of this, we change the invocation of pip to `python.exe -m pip`, as this is what is being recommended in Python docs these days. And it seemed to be required to avoid a weird build error. Why, I'm not sure. But it looks like pip was having trouble finding a Visual Studio files when invoked as `pip.exe` but not when using `python.exe -m pip`. Who knows. Differential Revision: https://phab.mercurial-scm.org/D8478
-
- Apr 21, 2020
-
-
Gregory Szorc authored
We initially implemented PyOxidizer support for Inno installers. That did most of the heavy work of integrating PyOxidizer into the packaging system. Implementing WiX installer support was pretty straightforward. Aspects of this patch look very similar to Inno's. The main difference is the handling of the Visual C++ Redistributable Runtime files. The WiX installer was formerly using merge modules to install the VC++ 9.0 runtime because this feature is supported by the WiX installer (it isn't easily available to Inno installers). Our strategy for the runtime files is to install the vcruntime140.dll file next to hg.exe just like any other file. While we could leverage WiX's functionality for invoking a VCRedist installer, I don't want to deal with the complexity at this juncture. So, we let run_pyoxidizer() copy vcruntime140.dll into the staging directory (like it does for Inno) and our dynamic WiX XML generator picks it up as a regular file and installs it. We did, however, have to teach mercurial.wxs how to conditionally use the merge modules. But this was rather straightforward. Comparing the file layout of the WiX installers before and after: * Various lib/*.{pyd, dll} files no longer exist * python27.dll was replaced by python37.dll * vcruntime140.dll was added All these changes are expected due to the transition to Python 3 and to PyOxidizer, which embeded the .pyd and .dll files in hg.exe. Differential Revision: https://phab.mercurial-scm.org/D8477
-
Gregory Szorc authored
With the previous commit moving signing inline, we no longer need to compute the version string in build_installer() and can instead move this logic to run_wix_packaging(). This makes the logic in build_installer() simpler, which makes it easier to implement alternate building mechanisms. Differential Revision: https://phab.mercurial-scm.org/D8476
-
Gregory Szorc authored
Previously, signing was implemented via a separate function which called build_installer() and then called signing functionality. In this model, in order to implement an alternative build mechanism, we would have to invent a new variant to handle signing as well. This commit merges the signing logic into the function invoking wix. If we pass an argument holding metadata about how to sign, we sign hg.exe and the installer. This means all we have to do is pass in signing info and the signing just works. A slight change here is that signing of hg.exe happens in the staging directory as opposed to before the staging directory is populated. I don't think this matters. Differential Revision: https://phab.mercurial-scm.org/D8475
-
Gregory Szorc authored
Like we did for Inno, we want to split out the building of Mercurial from invoking the packaging tool so that we can introduce an alternate build mechanism. As part of this refactor, there are inconsequential changes to file layouts. Before, some shared files such as the WiX binaries and merge modules would be installed under build/. Now, they are installed under build/wix-*. This is to keep implementation simpler. But it also helps keep build state more isolated. Differential Revision: https://phab.mercurial-scm.org/D8474
-
- Apr 24, 2020
-
-
Gregory Szorc authored
We want to start distributing Mercurial on Python 3 on Windows. PyOxidizer will be our vehicle for achieving that. This commit implements basic support for producing Inno installers using PyOxidizer. While it is an eventual goal of PyOxidizer to produce installers, those features aren't yet implemented. So our strategy for producing Mercurial installers is similar to what we've been doing with py2exe: invoke a build system to produce files then stage those files into a directory so they can be turned into an installer. We had to make significant alterations to the pyoxidizer.bzl config file to get it to produce the files that we desire for a Windows install. This meant differentiating the build targets so we can target Windows specifically. We've added a new module to hgpackaging to deal with interacting with PyOxidizer. It is similar to pyexe: we invoke a build process then copy files to a staging directory. Ideally these extra files would be defined in pyoxidizer.bzl. But I don't think it is worth doing at this time, as PyOxidizer's config files are lacking some features to make this turnkey. The rest of the change is introducing a variant of the Inno installer code that invokes PyOxidizer instead of py2exe. Comparing the Python 2.7 based Inno installers with this one, the following changes were observed: * No lib/*.{pyd, dll} files * No Microsoft.VC90.CRT.manifest * No msvc{m,p,r}90.dll files * python27.dll replaced with python37.dll * Add vcruntime140.dll file The disappearance of the .pyd and .dll files is acceptable, as PyOxidizer has embedded these in hg.exe and loads them from memory. The disappearance of the *90* files is acceptable because those provide the Visual C++ 9 runtime, as required by Python 2.7. Similarly, the appearance of vcruntime140.dll is a requirement of Python 3.7. Differential Revision: https://phab.mercurial-scm.org/D8473
-
- Apr 19, 2020
-
-
Gregory Szorc authored
We want to make the logic for producing the installer agnostic about how Mercurial is built to allow for alternate build methods (like PyOxidizer). Differential Revision: https://phab.mercurial-scm.org/D8472
-
Gregory Szorc authored
We have another version in rust/hgcli that is more modern and is already associated with our Rust CLI project. Differential Revision: https://phab.mercurial-scm.org/D8471
-
Gregory Szorc authored
For Linux, this was trivial. For Windows, we need to teach the powershell script to install Rust as well. This was also pretty straightforward. Differential Revision: https://phab.mercurial-scm.org/D8468
-
- Apr 30, 2020
-
-
Elmar Bartel authored
The previous method with sum() and list() creates a new list object for every hunk. Then sum() is used to flatten out this sequence of lists. The sum() function is not "lazy", but creates a new list object for every "+" operation and so this code had quadratic runtime behaviour.
-
- Apr 23, 2020
-
-
Raphaël Gomès authored
'.hg' would show up in `hg status` if were a symlink. Differential Revision: https://phab.mercurial-scm.org/D8461
-
- Apr 20, 2020
-
-
Raphaël Gomès authored
This is a gratuitous cleanup. Differential Revision: https://phab.mercurial-scm.org/D8460
-
- Apr 15, 2020
-
-
Pierre-Yves David authored
The `determineactions` function filters out deficiency that are not scheduled to be fixed by the target repository configuration. However it only did so for requirement we currently support, letting other actions for unsupported requirement through even if the target repo configuration did not request it. As a result the output of the command was easily polluted by experimental feature with no upgrade support. We rework the code to still filter out requirement based action without the faulty filtering. Differential Revision: https://phab.mercurial-scm.org/D8427
-
- Apr 13, 2020
-
-
Pierre-Yves David authored
Before this patch, the usual checking (especially, inline-ess) were not performed when warming the cache through `hg debugupdatecache`. This is now fixed. Differential Revision: https://phab.mercurial-scm.org/D8408
-
- Apr 16, 2020
-
-
Pierre-Yves David authored
The wait performed in increment of 0.01 second, but the timer was expressed in second. So we did not wait 20s, we waited 0.2 second. Internally we adjust the counter to be expressed in centisecond. This prevent some flackyness in the test. Differential Revision: https://phab.mercurial-scm.org/D8453
-
- Apr 20, 2020
-
-
Gregory Szorc authored
The previous commit revealed that attempting to run `python setup.py build_doc` from the packaging virtualenv failed due to missing docutils package. We didn't notice this before because py2exe Windows packaging appears to use a Python from another virtualenv (which does include docutils) to invoke setup.py. I discovered this as part of implementing packaging outside of that virtualenv environment. Differential Revision: https://phab.mercurial-scm.org/D8470
-
Gregory Szorc authored
Otherwise we get a str-bytes mismatch on Python 3 if an error occurs. Differential Revision: https://phab.mercurial-scm.org/D8469
-
- Mar 28, 2020
-
-
Gregory Szorc authored
Staying up to date. Keeping parity with the Windows environment. Differential Revision: https://phab.mercurial-scm.org/D8467
-
- Apr 22, 2020
-
-
Gregory Szorc authored
We would ideally update the 3.5 and 3.6 versions as well. But Python didn't generate exe installers for newer versions for some reason. Differential Revision: https://phab.mercurial-scm.org/D8466
-
- Apr 19, 2020
-
-
Gregory Szorc authored
The old AMI isn't available any more. We seem to run into this problem every few months. Amazon (or Microsoft) appears to be removing the old AMIs when they are superseded or something. Let's give up on tracking known images and switch the image selection logic to use the latest published image. Differential Revision: https://phab.mercurial-scm.org/D8465
-
- Apr 18, 2020
-
-
Matt Harbison authored
I think this is because Windows doesn't recognize single quote. Other ssh based clones use this clunky style too. Differential Revision: https://phab.mercurial-scm.org/D8459
-
- Apr 17, 2020
-
-
Matt Harbison authored
This was a missing update in 1b8fd4af3318. Differential Revision: https://phab.mercurial-scm.org/D8458
-
- Apr 16, 2020
-
-
Pulkit Goyal authored
-
Pulkit Goyal authored
-
Yuya Nishihara authored
Namespace registration is dynamic, but the corresponding template keyword is registered statically.
-
- Apr 13, 2020
-
-
Alexander Pyhalov authored
-
- Apr 05, 2020
-
-
Pierre-Yves David authored
We can get in a situation where a revision passed through `hg pull --rev REV` are available on the server, but not a descendant of the advertised server heads. For example the server could lying be during heads advertisement, to hide some pull request. Or obsolete/hidden content could be explicitly pulled. So in this case the lookup associated to `REV` returned successfully, but the normal discovery will find all advertised heads already known locally. This flip a special boolean `anyinc` that will prevent any fetch attempt, preventing `REV` to be pulled over. We add three line of code to detect this case and make sure a pull actually happens. My main target is to make some third party extensions happy (I expect the associated test to move upstream with the extension). However this fix already make some of the `infinitepush` test happier.
-
- Apr 15, 2020
-
-
Pierre-Yves David authored
This seems better and safer to be explicit. Differential Revision: https://phab.mercurial-scm.org/D8426
-
Pierre-Yves David authored
This is unnecessary and Mac OS X choke on them. Differential Revision: https://phab.mercurial-scm.org/D8425
-
- Apr 14, 2020
-
-
Valentin Gatien-Baron authored
It's more consistent, and makes it nicer to script around hg if you don't have to ignore exit code 255, which is the error code for basically everything in hg. Differential Revision: https://phab.mercurial-scm.org/D8423
-
- Apr 10, 2020
-
-
Jörg Sonnenberger authored
BSD-derived systems will use "ls -A" when running as root. Adjust the test cases to always use the flag and include .hg and related output as appropiately. Differential Revision: https://phab.mercurial-scm.org/D8397
-
Jörg Sonnenberger authored
Trying to check for errors on non-readable hgrc requires UNIX permissions, but still won't work for root. So adjust the check. Differential Revision: https://phab.mercurial-scm.org/D8396
-
Jörg Sonnenberger authored
It is not uncommon for cvs to check for root and to refuse work in that case. Differential Revision: https://phab.mercurial-scm.org/D8395
-
- Apr 16, 2020
-
-
Matt Harbison authored
This arg caused `gmake install` on OpenIndiana 2019.10 (illumos) fail with: install: The -c, -f, -n options each require a directory following! install: The -c, -f, -n options each require a directory following! install: The -c, -f, -n options each require a directory following! gmake[1]: *** [Makefile:41: install] Error 2 gmake[1]: Leaving directory '/usr/local/share/mercurial/doc' The workaround is to run `gmake install-bin`. The man page for 10.14 says this is to copy the file and is only for compatability, as it is the default. The CentOS 7 man page says it is ignored. The top level makefile doesn't use this argument at all, so I'm not sure why it's here. Differential Revision: https://phab.mercurial-scm.org/D8439
-
- Apr 14, 2020
-
-
Matt Harbison authored
Previously, posting a new review for a non head commit would orphan the head. The general case is any descendant of the selected revisions got orphaned if this was the first time the selected revisions were submitted. It doesn't happen when resubmitting. I've already had coworkers hit this a few times and get confused. Since posting a review isn't generally thought of as an editing operation, it would probably be easier for new users if we just restacked. This avoids restacking existing orphans around the submission because that may involve merge conflict resolution. Users who already have orphans should know how to stabilize them anyway. Differential Revision: https://phab.mercurial-scm.org/D8438
-
- Apr 12, 2020
-
-
Matt Harbison authored
I don't see why this would be useful in the first place. But I had a coworker submit a single commit that was not a branch head, and the result was to orphan its child and keep the original commit visible. He then did up arrow + Enter, and it happily created a new review (since the URL isn't amended into the original commit specified on the command line) and a new successor, resulting in a local divergence. I'd like to fix the issue with creating orphans, but this is simple enough to prevent on its own. Differential Revision: https://phab.mercurial-scm.org/D8437
-
- Mar 03, 2020
-
-
Matt Harbison authored
The instability occurred when rebasing something that has already been submitted onto something that hasn't, and then resubmitting the stack. Or as the test shows, just resubmitting and including something earlier that wasn't previously submitted. There's a general case here where any children (not just the ones in the range of commits posted for review) should be re-stabilized. But handling the selected commits here will cause the `local:commit` node values that are tracked on Phabricator to be properly kept in sync. Differential Revision: https://phab.mercurial-scm.org/D8436
-
- Apr 08, 2020
-
-
Matt Harbison authored
Now that all of the pieces are in place, alter the user facing command to allow it. This is the default behavior when using `arc`, but I much prefer the 1:1 approach, and I'm tempted to mark this advanced to limit its abuse. I started out calling this `--no-stack` like the feature request suggested, but I found it less obvious (especially when writing the code), so I went with the `hg fold` analogue. This will populate the `Commits` tab in the web UI with the hash of each commit folded into the review. From experimentation, it seems to list them in the order they are received from the extension instead of the actual parent/child relationship. The extension sends them in sorted order, thanks to `templatefilters.json()`. Since there's enough info there for them to put things in the right order, JSON is unordered aside from lists (IIUC), and there doesn't seem to be any harmful side effects, I guess we write this off as their bug. It is simple enough to workaround by putting a check for `util.sortdict` into `templatefilters.json()`, and don't resort in that case. There are a handful of restrictions that are documented in the code, which somebody could probably fix if they're interested. Notably, this requires the (default) `--amend` option, because there's not an easy way to apply a local tag across several commits. This also doesn't do preflight checking to ensure that all previous commits that were part of a single review are selected when updating. That seems expensive. What happens is the excluded commit is dropped from the review, but it keeps the Differential Revision line in the commit message. Not everything can be edited, so it doesn't seem worth making the code even more complicated to handle this edge case. There are a couple of "obsolete feature not enabled but X markers found!" messages that appeared on Windows but not macOS. I have no idea what's going on here, but that's an unrelated issue, so I conditionalized those lines. Differential Revision: https://phab.mercurial-scm.org/D8314
-
Matt Harbison authored
The next commit introduces a new repo to simplify its development. This value needs to be modified to record tests, so it doesn't make sense to have to do that twice. The callsign and URL are *not* moved because there are tests that fallback to the .arcconfig file when those aren't present. Differential Revision: https://phab.mercurial-scm.org/D8390
-