Skip to content
Snippets Groups Projects
  1. Feb 26, 2020
    • sliquister's avatar
      exchange: turn on option that makes concurrent pushes work better · edc8504bc26b
      sliquister authored
      The motivation is simply to make hg work better out of the box.
      
      This is a slight backwards compatibility break, because client
      extensions could have assumed that the list of heads the client sees
      during discovery will be the list of heads during the entirety of the
      push. It seems unlikely to matter, and not worth mentioning.
      
      There's a fair amount of diff in tests, but this is just due to
      sending a few more bytes on the wire, except for test-acl.t.
      The extra "invalid branch cache" lines in test-acl.t don't seem to
      indicate a problem: the branchcache now get computed during the bundle
      application (because of the check:updated-heads bundle part), but
      doesn't get rolled back when transactions rollback, thus causing a
      message in the next operation computing the branch cache. Before this
      change, I assume the branchcache was only computed on transaction
      commit, so not computed at all when the transactions roll back, thus
      no messages.
      
      Differential Revision: https://phab.mercurial-scm.org/D8202
      edc8504bc26b
  2. Mar 02, 2020
  3. Feb 28, 2020
  4. Feb 27, 2020
  5. Feb 26, 2020
  6. Feb 14, 2020
    • Martin von Zweigbergk's avatar
      debugmergestate: make templated · acbfa31cfaf2
      Martin von Zweigbergk authored
      Our IntelliJ team wants to be able to read the merge state in order to
      help the user resolve merge conflicts. They had so far been reading
      file contents from p1() and p2() and their merge base. That is not
      ideal for several reasons (merge base is not necessarily the "graft
      base", renames are not handled, commands like `hg update -m` is not
      handled). It will get especially bad as of my D7827. This patch makes
      the output s a templated. I haven't bothered to make it complete
      (e.g. merge driver states are not handled), but it's probably good
      enough as a start.
      
      I've done a web search for "debugmergestate" and I can't find any
      indication that any tools currently rely on its output. If it turns
      out that we get bug reports for it once this is released, I won't
      object to backing this patch out on the stable branch (and then
      perhaps replace it by a separate command, or put it behind a new
      flag).
      
      The changes in test-backout.t are interesting, in particular this:
      
      ```
        -    other path: foo (node not stored in v1 format)
        +    other path:  (node foo)
      ```
      
      I wonder if that means that we actually read v1 format
      incorrectly. That seems to be an old format that was switched away
      from in 2014, so it doesn't matter now anyway.
      
      Differential Revision: https://phab.mercurial-scm.org/D8120
      acbfa31cfaf2
    • Martin von Zweigbergk's avatar
      tests: add tests of debugmergestate with unresolved/resolved path conflicts · 382f4f09f0bd
      Martin von Zweigbergk authored
      I'm about to change `hg debugmergestate` and it broke on these "pu"
      and "pr" records on my first attempt (D8113), so let's add test
      coverage.
      
      Differential Revision: https://phab.mercurial-scm.org/D8119
      382f4f09f0bd
    • Martin von Zweigbergk's avatar
      mergestate: determine if active without looking for state files on disk · 5e3402a0b868
      Martin von Zweigbergk authored
      I couldn't think of a reason that we need to check state files on disk
      to determine if a merge is active. I could imagine them being for
      there for detecting broken state files that would then be cleaned up
      by some later command, but we always delete the entire `.hg/merge/`
      tree, so that doesn't seem to be it.
      
      The checks were added in 4e932dc5c113 (resolve: abort when not
      applicable (BC), 2014-04-18). Perhaps there were needed for that and
      then made obsolete by 6062593d8b06 (resolve: don't abort resolve -l
      even when no merge is in progress, 2014-05-23).
      
      The reason I want to delete the checks is that I think `ms =
      mergestate.read(repo); ms.active() and ms.local` should be a valid
      pattern, but it crashes when the merge state file is an empty file if
      we consider mere presence of the file as "active".
      
      Differential Revision: https://phab.mercurial-scm.org/D8118
      5e3402a0b868
  7. Feb 26, 2020
  8. Feb 18, 2020
    • Georges Racinet's avatar
      rust-nodemap: a method for full invalidation · d518994384a4
      Georges Racinet authored
      This will be used for exceptional operations,
      such as a `__delitem__` on the `MixedIndex` with
      Rust nodemap.
      
      In principle, `NodeTree` should also be able to forget
      an entry in an efficient way, by accepting to insert
      `Element::None` instead of only `Element::Rev(r)`,
      but that seems really overkill at this point. We need
      to support exceptional operations such as `__delitem__`,
      only for completeness of the revlog index as seen from
      Python. The Python callers don't seem to even really
      need it, deciding to drop the nodemap unconditionally at
      at higher level when calling `hg strip`. Also, `hg strip`
      is very costly for reasons that are unrelated to nodemap
      aspects.
      
      Differential Revision: https://phab.mercurial-scm.org/D8098
      d518994384a4
    • Georges Racinet's avatar
      rust-nodemap: accounting for dead blocks · 6329ce04c69f
      Georges Racinet authored
      By the very append-only nature of the `NodeTree`, inserting
      new blocks has the effect of making some of the older ones
      useless as they become unreachable.
      
      Therefore some automatic housekeeping will need to be provided.
      This is standard procedure in the word of databases, under names
      such as "repack" or "vacuum".
      
      The new `masked_readonly_blocks()` will provide callers with
      useful information to decide if the nodetree is ripe for
      repacking, but all the `NodeTree` can provide is how many
      blocks have been masked in the currently mutable part. Analysing
      the readonly part would be way too long to do it for each
      transaction and defeat the whole purpose of nodemap persistence.
      Serializing callers (from the Python layer) will get this figure
      before each extraction and maintain an aggregate counter of
      unreachable blocks separately.
      
      Note: at this point, the most efficient repacking is just to restart
      afresh with a full rescan.
      
      Differential Revision: https://phab.mercurial-scm.org/D8097
      6329ce04c69f
    • Georges Racinet's avatar
      rust-nodemap: core implementation for shortest · 5ac1eecc9c64
      Georges Racinet authored
      In this implementation, we just make `lookup()` return also the number
      of steps that have been needed to come to a conclusion from the
      nodetree data, and `validate_candidate()` takes care of the special
      cases related to `NULL_NODE`.
      
      This way of doing minimizes code duplication, but it means that
      the comparatively slower finding of first non zero nybble will run
      for all calls to `find()` where it is not needed.
      
      Still running on the file generated for the mozilla-central repository,
      it seems indeed that we now get more ofter 320 ns than 310. The odds that
      this could have a significant impact on real life Mercurial performance
      are still looking low. Let's wait for actual benchmark runs to see if
      an optimization is needed here.
      
      Differential Revision: https://phab.mercurial-scm.org/D7819
      5ac1eecc9c64
    • Georges Racinet's avatar
      rust-nodemap: special case for prefixes of NULL_NODE · 00d251d32007
      Georges Racinet authored
      We have to behave as though NULL_NODE was stored in the node tree,
      although we don't store it.
      
      Differential Revision: https://phab.mercurial-scm.org/D7798
      00d251d32007
    • Georges Racinet's avatar
      rust-nodemap: pure Rust example · 8f7c6656ac79
      Georges Racinet authored
      To run, use `cargo run --release --example nodemap`
      
      This demonstrates that simple scenarios entirely written
      in Rust can content themselves with `NodeTree<T>`.
      
      The example mmaps both the nodemap file and the changelog index.
      We had of course to include an implementation of `RevlogIndex`
      directly, which isn't much at this stage. It felt a bit
      prematurate to include it in the lib.
      
      Here are some first performance measurements, obtained with
      this example, on a clone of mozilla-central with 440000
      changesets:
      
        (create) Nodemap constructed in RAM in 153.638305ms
        (query CAE63161B68962) found in 22.362us: Ok(Some(269489))
        (bench) Did 3 queries in 36.418µs (mean 12.139µs)
        (bench) Did 50 queries in 184.318µs (mean 3.686µs)
        (bench) Did 100000 queries in 31.053461ms (mean 310ns)
      
      To be fair, even between bench runs, results tend to depend whether
      the file is still in kernel caches, and it's not so easy to
      get back to a real cold start. The worst we've seen was in the
      50us ballpark.
      
      In any busy server setting, the pages would always be in RAM.
      
      We hope it's good enough not to be significantly slower on any
      concrete Mercurial operation than the C nodetree when fully in RAM,
      and of course this implementation has the serious headstart advantage
      of persistence.
      
      Differential Revision: https://phab.mercurial-scm.org/D7797
      8f7c6656ac79
    • Georges Racinet's avatar
      rust-nodemap: input/output primitives · a98ba6983a63
      Georges Racinet authored
      These allow to initiate a `NodeTree` from an immutable opaque
      sequence of bytes, which could be passed over from Python
      (extracted from a `PyBuffer`) or directly mmapped from a file.
      
      Conversely, we can consume
      a `NodeTree`, extracting the bytes that express what
      has been added to the immutable part, together with the
      original immutable part.
      This gives callers the choice to start a new Nodetree.
      After writing to disk, some would prefer to reread for
      best guarantees (very cheap if mmapping), some others will
      find it more convenient to grow the memory that was considered
      immutable in the `NodeTree` and continue from there.
      
      This is enough to build examples running on real data and
      start gathering performance hints.
      
      Differential Revision: https://phab.mercurial-scm.org/D7796
      a98ba6983a63
  9. Feb 13, 2020
  10. Feb 18, 2020
    • sliquister's avatar
      graft: always allow hg graft --base . (issue6248) · 218feb1a7e00
      sliquister authored
      `hg graft --base . -r abc` is rejected before this change with a
      "nothing to merge" error, if `abc` does not descend from `.`.
      
      This looks like an artifact of the implementation rather than intended
      behavior. It makes perfect sense to apply the diff between `.` and
      `abc` to the working copy (i.e. degenerate into `hg revert`),
      regardless of what `abc` is.
      
      Differential Revision: https://phab.mercurial-scm.org/D8127
      218feb1a7e00
  11. Feb 19, 2020
  12. Feb 25, 2020
  13. Feb 24, 2020
  14. Feb 14, 2020
    • sliquister's avatar
      bookmarks: prevent pushes of divergent bookmarks (foo@remote) · 8407031f195f
      sliquister authored
      Before this change, such bookmarks are write-only: a client can push
      them but not pull/read them. And because these bookmark can't be read,
      even pushes are limited (for instance trying to delete such a bookmark
      fails with a vanilla client because the client thinks the bookmark is
      neither on the local nor the remote).
      
      This change makes the server refuses such bookmarks, and for earlier
      errors, makes the client refuse to send them.
      
      I think the change of behavior is acceptable because I think this is a
      bug in push/pull, and I don't think we change the behavior of `hg
      unbundle`, because it doesn't seem that `hg bundle` ever store
      bookmarks (and even if it did, it would seem weird anyway to try to
      send divergent bookmarks).
      
      Differential Revision: https://phab.mercurial-scm.org/D8117
      8407031f195f
    • sliquister's avatar
      bookmarks: refactor in preparation for next commit · 0275000564c4
      sliquister authored
      Differential Revision: https://phab.mercurial-scm.org/D8116
      0275000564c4
  15. Feb 15, 2020
  16. Feb 20, 2020
  17. Dec 20, 2019
    • Martin von Zweigbergk's avatar
      copy: add experimental support for marking committed copies · 9dab3fa64325
      Martin von Zweigbergk authored
      The simplest way I'm aware of to mark a file as copied/moved after
      committing is this:
      
        hg uncommit --keep <src> <dest>  # <src> needed for move, but not copy
        hg mv --after <src> <dest>
        hg amend
      
      This patch teaches `hg copy` a `--at-rev` argument to simplify that
      into:
      
        hg copy --after --at-rev . <src> <dest>
      
      In addition to being simpler, it doesn't touch the working copy, so it
      can easily be used even if the destination file has been modified in
      the working copy.
      
      Differential Revision: https://phab.mercurial-scm.org/D8035
      9dab3fa64325
Loading