Skip to content
Snippets Groups Projects
  1. Mar 03, 2021
  2. Sep 05, 2020
  3. Aug 26, 2020
  4. Mar 01, 2021
  5. Feb 27, 2021
  6. Feb 23, 2021
  7. Dec 22, 2020
  8. Feb 17, 2021
  9. Feb 24, 2021
  10. Feb 12, 2021
  11. Feb 22, 2021
  12. Feb 23, 2021
    • Kyle Lippincott's avatar
      obslog: correct help to state that obslog is the command name · bf74edda
      Kyle Lippincott authored
      Right now, `hg help obslog` says the following, which is a bit confusing:
      
      ```
      hg olog [OPTION]... [[-r] REV]...
      
      aliases: olog
      ```
      
      Since the primary command name is determined by the order the commands are
      defined in, and we use 'obslog' as the name for the pager, I've chosen
      `hg obslog` as the canonical name and am only adjusting the help string.
      bf74edda
  13. Feb 22, 2021
  14. Feb 17, 2021
  15. Feb 22, 2021
  16. Jan 24, 2021
    • Pierre-Yves David's avatar
      divergence-resolution: [patch 3] fix a messed up test case · 961a940a
      Pierre-Yves David authored
      Because of logic change in divergence resolution which causes the order change
      in picking the resolution parent this test case was messed up.
      
      It was supposed to test that it hits merge conflict while merging the
      two divergent csets but because of some change in previous patches, we hit
      conflict early during relocation of one of the cset.
      
      This patch, by resolving the conflict for relocation make sure that we test
      the conflict while merging the two divergent csets.
      961a940a
    • Pierre-Yves David's avatar
      divergence-resolution: [patch 2] fix a messed up test case · 32c0b289
      Pierre-Yves David authored
      Because of logic change in divergence resolution which causes the order change
      in picking the resolution parent this test case was messed up.
      
      It was supposed to test that that it hits conflict while relocating the
      divergent cset but because of some change in previous patches, relocation went
      successful and it hits conflict while merging the two divergent csets.
      
      This patch, by making some changes in files content make sure that we get
      conflict during relocation.
      32c0b289
    • Pierre-Yves David's avatar
      divergence-resolution: [patch 1] fix a messed up test case · c0122b98
      Pierre-Yves David authored
      Because of logic change in divergence resolution which causes the order change
      in picking the resolution parent this test case was messed up.
      
      It was supposed to test that that it hits conflict while relocating the
      divergent cset but because of some change in previous patches, relocation went
      successful and it hits conflict while merging the two divergent csets.
      
      This patch, by making some changes in files content make sure that we get
      conflict during relocation.
      c0122b98
  17. Feb 17, 2021
  18. Feb 18, 2021
  19. Feb 01, 2021
  20. Jan 22, 2021
  21. Jan 28, 2021
  22. Feb 17, 2021
    • Kyle Lippincott's avatar
      doc: switch rst `=` section underlines to `-` · e117cf74
      Kyle Lippincott authored
      When using GENDOC_LOAD_CONFIGURED_EXTENSIONS=1, Mercurial's doc/gendoc.py can
      load extensions from outside of just the hgext directory, and pull in this doc.
      
      When added to the documentation, this should be nested inside of the following
      extension hierarchy:
      
      - Extensions
        - evolve
      
      The generated documentation has an established hierarchy of section headers, and
      the above uses `"` for top level, and `=` for each extension. Since gendoc just
      pastes it in verbatim, with `=` underlines, we get "Obsolescence Markers
      Discovery", "Effect Flag Experiment", and "Template keywords" as siblings to the
      evolve extension, instead of nested inside of it.
      
      This is not required for the string below it (that shows up with
      `hg help evolution`), as that is one level higher in the hierarchy (not nested
      inside of an "Extensions" section), so `=` is appropriate there.
      e117cf74
    • Kyle Lippincott's avatar
      doc: remove .strip() for a docstring · 96ed73c5
      Kyle Lippincott authored
      This shouldn't be necessary, and by stripping it (and removing the trailing
      newline) it causes issues with Mercurial's doc/gendoc.py's RST output, since
      there's no newline separating this string and the thing that comes after it.
      
      I believe that the `.strip()` has been in there since the beginning, but I have
      not found a reason for its existence. It's possible that this was required in
      older Mercurial versions, but is no longer required? Notably, the tests (which
      include an invocation of `hg help evolution`) still pass with this change.
      
      ### Alternatives considered
      
      - Making gendoc.py robust against this. This was rejected since there's no need
        for the .strip() as far as I can tell, and this is the only case I know of
        that would need such logic.
      96ed73c5
  23. Nov 25, 2020
    • Martin von Zweigbergk's avatar
      evolvecmd: don't update working copy when using in-memory merge · 84affb25
      Martin von Zweigbergk authored
      This patch removes the update of the working copy after each in-memory
      merge and only instead updates the working copy afterwards (if
      requested).
      
      There's still no significant speedup in the hg repo. It seems that the
      cost of updating the working copy is not large enough to make much
      difference, and the cost of reading and updating obsmarkers is
      relatively high in that repo. A significant part of the time (~35%) is
      spent in `repoview.computehidden()` because it is recalculated for
      every commit (seems like potential for improvement).
      
      I made similar changes in the mozilla-unified repo (which has a
      significantly larger working copy), by adding 10 commits each changing
      one line of a file. There, evolving 9 of those commits took 34s before
      this patch and 20s after. I measured similar speedups in an internal
      repo (9.0s -> 5.2s).
      84affb25
  24. Oct 15, 2020
    • Martin von Zweigbergk's avatar
      evolve: when relocating, optionally first try to do it using in-memory merge · c5dfbbe4
      Martin von Zweigbergk authored
      This patch adds a config option to let run evolve's relocation step
      using in-memory merge. It is disabled by default. When the option is
      on, the relocation is first attempted in memory. If that fails because
      of merge conflicts, it retries that commit in the working copy.
      
      There are a few reasons that I made it configurable. The most
      important one is that the precommit hook won't trigger when using
      in-memory merge. Another reason is that it lets us roll out the
      feature slowly to our users at Google.
      
      For now, we also update the working copy after creating the commit (in the
      successful case, when there are no merge conflicts). The next patch will make it
      so we don't do that update.
      
      Because of the unnecessary working-copy update, this patch doesn't
      provide any benefit on its own. Evolving 29 commits that each change
      one line in the hg slows down from ~4.5s to ~4.8s when the config
      option is on.
      
      I've added `#testcases inmemory ondisk` to select `.t` files. Almost
      all differences are because of the new "hit merge conflicts" message
      and retrying the merge. There's also one difference in
      `test-stabilize-order.t` caused by the different order of working copy
      updates (we now update the working copy at the end).
      c5dfbbe4
  25. Oct 01, 2020
  26. Oct 15, 2020
  27. Feb 09, 2021
Loading