Skip to content
Snippets Groups Projects
  1. Apr 24, 2020
    • Gregory Szorc's avatar
      automation: support building Windows wheels for Python 3.7 and 3.8 · 9d441f82
      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
      9d441f82
  2. Apr 21, 2020
    • Gregory Szorc's avatar
      packaging: support building WiX installers with PyOxidizer · 234882d1
      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
      234882d1
    • Gregory Szorc's avatar
      packaging: move version derivation to run_wix_packaging() · a5740490
      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
      a5740490
    • Gregory Szorc's avatar
      packaging: integrate signing into run_wix_packaging() · a3998409
      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
      a3998409
    • Gregory Szorc's avatar
      packaging: isolate invocation of WiX to own function · 92627c42
      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
      92627c42
  3. Apr 24, 2020
    • Gregory Szorc's avatar
      packaging: support building Inno installer with PyOxidizer · 94f4f2ec
      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
      94f4f2ec
  4. Apr 19, 2020
  5. Apr 30, 2020
    • Elmar Bartel's avatar
      diff: re-establish linear runtime performance · e58422af
      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.
      e58422af
  6. Apr 23, 2020
  7. Apr 20, 2020
  8. Apr 15, 2020
    • Pierre-Yves David's avatar
      upgrade: properly filter action depending on planned work · c36a3fcf
      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
      c36a3fcf
  9. Apr 13, 2020
  10. Apr 16, 2020
  11. Apr 20, 2020
  12. Mar 28, 2020
  13. Apr 22, 2020
  14. Apr 19, 2020
    • Gregory Szorc's avatar
      automation: always use latest Windows AMI · 828d3277
      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
      828d3277
  15. Apr 18, 2020
  16. Apr 17, 2020
  17. Apr 16, 2020
  18. Apr 13, 2020
  19. Apr 05, 2020
    • Pierre-Yves David's avatar
      discovery: avoid wrongly saying there are nothing to pull · b561f3a6
      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.
      b561f3a6
  20. Apr 15, 2020
  21. Apr 14, 2020
  22. Apr 10, 2020
  23. Apr 16, 2020
    • Matt Harbison's avatar
      make: drop the `-c` arg to `install` in the documentation makefile · eb9026a8
      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
      eb9026a8
  24. Apr 14, 2020
    • Matt Harbison's avatar
      phabricator: restack any new orphans created by phabsend (issue6045) · 601ce539
      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
      601ce539
  25. Apr 12, 2020
    • Matt Harbison's avatar
      phabricator: prevent posting obsolete commits · c482e2fe
      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
      c482e2fe
  26. Mar 03, 2020
    • Matt Harbison's avatar
      phabricator: avoid creating unstable children within the review stack · 0680b8a1
      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
      0680b8a1
  27. Apr 08, 2020
    • Matt Harbison's avatar
      phabricator: add an option to fold several commits into one review (issue6244) · 3dc6a707
      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
      3dc6a707
    • Matt Harbison's avatar
      tests: move the phabricator auth token to the global config file · ed81fa85
      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
      ed81fa85
Loading