Skip to content
Snippets Groups Projects
  1. Dec 23, 2020
  2. Dec 21, 2020
  3. Dec 15, 2020
  4. Dec 12, 2020
  5. Dec 14, 2020
    • Pierre-Yves David's avatar
      copies: rearrange all value comparison conditional · 367e0743
      Pierre-Yves David authored
      To properly handle the newly tested case (chaining of merges) we will need to
      detect more accurately when an actualy merging of the copy information (and
      superseed the two existing data). Before starting to do so, we need to
      reorganise the values comparison to introduce different conditional branches
      when such actual merging is needed/detected.
      
      To avoid mixing too many change in this complicated code, we do the
      reorganisation before adding the "overwrite detection" logic in the next
      changesets.
      
      Differential Revision: https://phab.mercurial-scm.org/D9612
      367e0743
    • Pierre-Yves David's avatar
      copies-test: add test chaining multiple merge · 6c0fe960
      Pierre-Yves David authored
      Right now, the copy tracing logic take the right decision for merges, but it
      does not keep track of the right information about these decision and can fall
      into later traps. We start with highlighting this possibility by adding new
      tests, and we will fix them later.
      
      Check the inline test documentation for details.
      
      Differential Revision: https://phab.mercurial-scm.org/D9611
      6c0fe960
    • Pierre-Yves David's avatar
      copies-test: add test chaining multiple merges · 252a55f3
      Pierre-Yves David authored
      Right now, the copy tracing logic take the right decision for merges, but it
      does not keep track of the right information about these decision and can fall
      into later traps. We start with highlighting this possibility by adding new
      tests, and we will fix them later.
      
      Check the inline test documentation for details.
      
      Differential Revision: https://phab.mercurial-scm.org/D9610
      252a55f3
  6. Feb 16, 2021
  7. Feb 15, 2021
    • Pierre-Yves David's avatar
      test-copies: don't use empty file for "same content" cases · af49714d
      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
      af49714d
  8. Dec 10, 2020
    • Pierre-Yves David's avatar
      test-copies: reinstall initial identical (empty) files for chained copied · 0cb70022
      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
      0cb70022
  9. Feb 04, 2021
  10. Jan 27, 2021
  11. Jan 26, 2021
  12. Feb 08, 2021
  13. Feb 04, 2021
  14. 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
  15. Feb 12, 2021
  16. Feb 10, 2021
Loading