Skip to content
Snippets Groups Projects
  1. May 12, 2020
  2. May 11, 2020
    • Martin von Zweigbergk's avatar
      revisions: parse "x123" as "nodeid starting with 123" without prefixhexnode · 62435a5b
      Martin von Zweigbergk authored
      `experimental.revisions.prefixhexnode` makes it so the template
      function `shortest()` uses an "x" prefix to disambiguate between short
      nodeids and revnums. That config has so far also been used for
      enabling parsing of "x123" unambiguously as a nodeid. That makes it a
      little annoying for people who have prefixhexnode=yes to share such
      nodeids with people who have prefixhexnode=no ("x123" will be
      considered invalid for them). There seems to be little harm in
      allowing that parsing for everyone. We still let e.g. bookmark names
      like "x123" take precedence over the nodeid, so that's not a
      concern. The only thing I can think of is that people get used to the
      "x" prefix being valid, making it impossible for us to change to a
      different prefix if we wanted to do that when graduating the feature.
      
      Differential Revision: https://phab.mercurial-scm.org/D8514
      62435a5b
  3. May 08, 2020
  4. May 06, 2020
  5. Apr 15, 2020
  6. Apr 21, 2020
  7. Apr 14, 2020
  8. Apr 15, 2020
    • Pierre-Yves David's avatar
      upgrade: support the --quiet flag · e295ba23
      Pierre-Yves David authored
      The command is currently very verbose with a various bit of output being time
      sensitive or randomized. The make invocation bulky and hard to match in the
      test. We move various message from `ui.write` to `ui.status` in order for the
      `--quiet` flag to have effect and helps the situation.
      
      As a side benefit, we can replace the various redirection to > /dev/null with the --quiet flag.
      
      Differential Revision: https://phab.mercurial-scm.org/D8429
      e295ba23
    • Pierre-Yves David's avatar
      upgrade: clearly list optimisations · 5ee4b211
      Pierre-Yves David authored
      This makes the command operation clearer. And this will be necessary to have
      a short version of this information with the next changesets, teaching `hg
      debugupgraderepo` about `--quiet`.
      
      Differential Revision: https://phab.mercurial-scm.org/D8428
      5ee4b211
  9. Apr 14, 2020
  10. Apr 05, 2020
    • Pierre-Yves David's avatar
      nodemap: also warm manifest nodemap with other caches · 97ebdb19
      Pierre-Yves David authored
      The `hg debugupdatecache` command now also warm the persistent nodemap for the
      manifest (when applicable).
      
      Differential Revision: https://phab.mercurial-scm.org/D8411
      97ebdb19
    • Pierre-Yves David's avatar
      nodemap: also use persistent nodemap for manifest · 640d5b3b
      Pierre-Yves David authored
      The manifest as a different usage pattern than the changelog. First, while the
      lookup in changelog are not garanteed to match, the lookup in the manifest
      nodemap come from changelog and will exist in the manifest. In addition, looking
      up a manifest almost always result in unpacking a manifest an operation that
      rarely come cheap.
      
      Nevertheless, using a persistent nodemap provide a significant gain for some
      operations.
      
      
      For our measurementw, we use `hg cat --rev REV FILE` on the our reference
      mozilla-try. On this repository the persistent nodemap cache is about 29 MB in
      side for a total store side of 11,988 MB
      
      File with large history (file: b2g/config/gaia.json, revision: 195a1146daa0)
      
          no optimisation:                             0.358s
          using mmap for index:                        0.297s (-0.061s)
          persistent nodemap for changelog only:       0.275s (-0.024s)
          persistent nodemap for manifest too:         0.258s (-0.017s)
      
      File with small history (file: .hgignore, revision: 195a1146daa0)
      
          no optimisation:                             0.377s
          using mmap for index:                        0.296s (-0.061s)
          persistent nodemap for changelog only:       0.274s (-0.022s)
          persistent nodemap for manifest too:         0.257s (-0.017s)
      
      Same file but using a revision (8ba995b74e18) with a smaller manifest (3944829
      bytes vs  10 bytes)
      
          no optimisation:                             0.192s (-0.185s)
          using mmap for index:                        0.131s (-0.061s)
          persistent nodemap for changelog only:       0.106s (-0.025s)
          persistent nodemap for manifest too:         0.087s (-0.019s)
      
      Differential Revision: https://phab.mercurial-scm.org/D8410
      640d5b3b
    • Pierre-Yves David's avatar
      nodemap: create files in the repository used in the test · 2c073d82
      Pierre-Yves David authored
      We need a manifest with more content to test persistent nodemap for manifest.
      This change the repository content and affect all the hashes.
      
      Differential Revision: https://phab.mercurial-scm.org/D8409
      2c073d82
  11. May 07, 2020
  12. May 04, 2020
  13. May 01, 2020
  14. Mar 05, 2020
    • Pierre-Yves David's avatar
      copies: fix the changeset based algorithm regarding merge · 45f3f35c
      Pierre-Yves David authored
      In 99ebde4fec99, we changed the list of files stored into the `files` field.
      This lead to the changeset centric copy algorithm to break in various merge
      situation involving merge. Older information could reach the merge through
      `p1`, and while information from `p2` was strictly fresher, it would get
      overwritten anyway.
      
      We update the situation with more details about which revision introduces rename
      information. This help use making the right decision in case of merge.
      
      We are now running a more comprehensive suite of test with include this kind of
      situation. The behavior differ slightly from the filelog based in a couple of
      instance. There is mostly two distinct cases:
      
      1) there are conflicting rename information in a merge (different rename history
      on each side). In this case the filelog based implementation arbitrarily pick a
      side based on the file-revision-number. So it depends on a local factor. The
      changeset centric algorithm will use a deterministic approach, by picking the
      information coming from the first parent of the merge. This is stable across
      different clone.
      
      2) rename information related to file that exist in both source and destination.
      The filelog based implementation do not even try to detect these, however the
      changeset centric one get them for "free" (it is simpler to detect them than
      not).
      
      The new implementation focus on correctness. Performance improvement will come
      later.
      
      Differential Revision: https://phab.mercurial-scm.org/D8244
      45f3f35c
  15. May 01, 2020
  16. Apr 16, 2020
  17. Apr 24, 2020
    • Gregory Szorc's avatar
      automation: support building Python 3 MSI installers · 5e788dc7
      Gregory Szorc authored
      This is very similar to what we just did for Inno.
      
      Differential Revision: https://phab.mercurial-scm.org/D8484
      5e788dc7
    • Gregory Szorc's avatar
      automation: support building Python 3 Inno installers · 802ee93c
      Gregory Szorc authored
      The core packaging code now supports building Python 3 installers
      using PyOxidizer. Let's teach the automation code to invoke it so
      that we produce both Python 2 and Python 3 based exe installers.
      
      When publishing the artifacts, the Python 3 versions are preferred
      over the Python 2 versions given their higher weight (10 versus 9).
      This may be a controversial change. But I think making Python 3
      the default is warranted, as it is the future. The Python 2 installers
      are still fully supported and can be installed should issues with
      Python 3 arise.
      
      Differential Revision: https://phab.mercurial-scm.org/D8483
      802ee93c
    • Gregory Szorc's avatar
      automation: add extra arguments when building Inno · 47609da1
      Gregory Szorc authored
      These were being fed into the template expansion but not being
      used. This meant --version was not getting set when it should have
      been.
      
      Differential Revision: https://phab.mercurial-scm.org/D8482
      47609da1
    • Gregory Szorc's avatar
      packaging: add -python2 to Windows installer filenames · 9ade217b
      Gregory Szorc authored
      We just taught the Windows installers to produce Python 3 variants
      built with PyOxidizer.
      
      Our plan is to publish both Python 2 and Python 3 versions of the
      installers for Mercurial 5.4.
      
      This commit teaches the Inno and WiX installers to add an optional
      string suffix to the installer name. On Python 2, that suffix is
      "-python2." We reserve the existing name for the Python 3 installers,
      which we want to make the default.
      
      Differential Revision: https://phab.mercurial-scm.org/D8479
      9ade217b
    • 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
Loading