Skip to content
Snippets Groups Projects
  1. Feb 16, 2021
  2. Feb 22, 2021
    • Pierre-Yves David's avatar
      test-copies: don't use empty file for "same content" cases · d4688511
      Pierre-Yves David authored
      For main case (using filelog  or sidedata), this lead to the following hash
      change.
      
      Changesets:
      
      - 01c2f5eabdc4ce2bdee42b5f86311955e6c8f573 → 319179230cc87769ab3a861ebffe7a534ebb3d85
      - 01c2f5eabdc4 → 319179230cc8
      - c72365ee036fca4fb27fd745459bfb6ea1ac6993 → 6cbc9c2b7b391dd738603173717c601648d3735f
      - c72365ee036f → 6cbc9c2b7b39
      
      File revision for `f`:
      
      - 0dd616bc7ab1a111921d95d76f69cda5c2ac539c → cedeacc5bf5d9b9be4d7f8394d33a5349bb29c6e
      - 0dd616bc7ab1 → cedeacc5bf5d
      - eb806e34ef6be4c264effd5933d31004ad15a793 → ffb76cd765422a18759a335d8a81fa2bd455be6b
      - eb806e34ef6b → ffb76cd76542
      - 6da5a2eecb9c833f830b67a4972366d49a9a142c → 08d1ff5926fbd0285cdeb044cbe8ab651687e86a
      - 6da5a2eecb9c → 08d1ff5926fb
      
      File revision for `d`:
      
      - 7bded9d9da1f7bf9bf7cbfb24fe1e6ccf68ec440 → ba177bbb45ea930ee48469a55d40224537bd57a9
      
      For the "extra in changeset" case we get the following change for file `d`:
      
      - 68d5bca9df0577b6bc2ea30ca724e13ead60da81 → b894de5c94aadcb4894ea7c358389819c27fbcce
      - 68d5bca9df05 → b894de5c94aa
      - b80de5d138758541c5f05265ad144ab9fa86d1db → 56647659eff080e06e45c18ea9e848836dadea71
      - b80de5d13875 → 56647659eff0
      d4688511
  3. Dec 10, 2020
    • Pierre-Yves David's avatar
      test-copies: reinstall initial identical (empty) files for chained copied · 018d622e
      Pierre-Yves David authored
      This effectively back out changeset deeb215be337. Changeset deeb215be337 does not
      really include a justification for its change and make mes uncomfortable. I have
      been thinking about it and they are two options:
      
      - either having empty/full files does not make a difference, and deeb215be337 is
        a gratuitous changes.
      
      - either having empty/full files do make a difference and deeb215be337 silently
        change the test coverage. In such situation if we want the "not empty" case to
        be tested, we should add new cases to cover them
      
      In practice, we know that the "file content did not change, but merge still need
      to create a new filenode" case exists (for example if merging result in similar
      content but both parent of the file need to be recorded), and that such case are
      easy to miss/mess-up in the tests. Having all the file using the same (empty)
      content was done on purpose to increase the coverage of such corner case.
      
      As a result I am reinstalling the previous test situation. To
      increase the coverage of some case involving content-merge in
      test-copies-chain-merge.t, we will add a new, dedicated, cases later in this
      series, once various cleanup and test improvement have been set in place.
      
      This changeset starts with reinstalling the previous situation as (1) it is more
      fragile, so I am more confided getting it back in the initial situation, (2) I
      have specific test further down the line that are base on these one.
      
      The next changeset will slightly alter the test to use non-empty files for these
      tests (with identical content). It should help to make the initial intent "merge file with identical
      content" clearer. I am still using a two steps (backout, then change content)
      approach to facilitate careful validation of the output change.
      
      Doing so has a large impact on the output of the "copy info in changeset extra" variant
      added in 5e72827dae1e (2 changesets after deeb215be337). It seems to highlight
      various breakage when merge without content change are involved, this is a good
      example of why we want to explicitly test theses cases. Because the different
      -do- matters a lot.
      
      Fixing the "copy info in changeset extra" is not a priority here. Because (1)
      this changeset does not break anything, it only highlight that they were always
      broken. (2) the only people using "copy info in changeset extra" do not have
      merge.
      
      Differential Revision: https://phab.mercurial-scm.org/D9587
      018d622e
  4. Feb 10, 2021
  5. Feb 15, 2021
  6. Feb 23, 2021
  7. Feb 11, 2021
    • Kyle Lippincott's avatar
      packaging: add Provides: python3-mercurial and Homepage to debian package · c82d6363
      Kyle Lippincott authored
      There are other packages that depend on python3-mercurial, like debian's
      mercurial-git, so we should mark ourselves as providing it.
      
      I compared the control file we generate to the one that the debian maintainers
      generate, and noticed several differences:
      - the Homepage bit. I included this, because why not
      - a more robust Suggests list that includes a graphical merge tool
      - a more robust Breaks list
      - debian's Recommends openssh-client, we only Recommends ca-certificates
      - a split into `mercurial` and `mercurial-common` (and possibly others?)
      - a slightly different description
      
      Differential Revision: https://phab.mercurial-scm.org/D9983
      c82d6363
  8. Feb 12, 2021
  9. Feb 10, 2021
  10. Feb 12, 2021
  11. Feb 04, 2021
  12. Jan 27, 2021
  13. Jan 26, 2021
  14. Feb 08, 2021
  15. Feb 04, 2021
  16. Dec 24, 2020
    • Matt Harbison's avatar
      tagcache: distinguish between invalid and missing entries · 5aac1a1a
      Matt Harbison authored
      The TortoiseHg repo has typically not had a newly applied tag accessible by name
      for recent releases, for unknown reasons.  Deleting and rebuilding the tag cache
      doesn't fix it, though deleting the cache and running `hg log -r $new_tag` does.
      Eventually the situation does sort itself out for new clones from the server.
      In an effort to figure out what the issue is, Pierre-Yves David suggested
      listing these entries in the debug output more specifically.
      
      This isn't complete yet- the second test change that says "missing" is more like
      "invalid", since it was truncated.  The problem there is the code that reads the
      raw array truncates any partial records and then fills it with 0xFF, which
      signifies that it is missing.  As a side note, that means the check for the
      length when validating an existing entry never fails.
      
      Differential Revision: https://phab.mercurial-scm.org/D9811
      5aac1a1a
Loading