Skip to content
Snippets Groups Projects
  1. Apr 17, 2019
  2. Apr 02, 2019
  3. Dec 28, 2017
    • Martin von Zweigbergk's avatar
      changelog: parse copy metadata if available in extras · 5382d8f8530b
      Martin von Zweigbergk authored
      This lets read back the copy metadata we just started writing. There
      are still many places left to teach about getting the copy information
      from the changeset, but we have enough ({file_copies}, specifically)
      that we can add it now and have some test coverage of it.
      
      Differential Revision: https://phab.mercurial-scm.org/D6186
      5382d8f8530b
    • Martin von Zweigbergk's avatar
      copies: add config option for writing copy metadata to file and/or changset · 0e41f40b01cc
      Martin von Zweigbergk authored
      This introduces a config option that lets you choose to write copy
      metadata to the changeset extras instead of to filelog. There's also
      an option to write it to both places. I imagine that may possibly be
      useful when transitioning an existing repo.
      
      The copy metadata is stored as two fields in extras: one for copies
      since p1 and one for copies since p2.
      
      I may need to add more information later in order to make copy tracing
      faster. Specifically, I'm thinking out recording which files were
      added or removed so that copies._chaincopies() doesn't have to look at
      the manifest for that. But that would just be an optimization and that
      can be added once we know if it's necessary.
      
      I have also considered saving space by using replacing the destination
      file path by an index into the "files" list, but that can also be
      changed later (but before the feature is ready to release).
      
      Differential Revision: https://phab.mercurial-scm.org/D6183
      0e41f40b01cc
  4. Apr 04, 2019
  5. Apr 12, 2019
    • Pierre-Yves David's avatar
      repoview: flag `server.view` as experimental · 08481e11462e
      Pierre-Yves David authored
      Ideally, the non-experimental version of `experimental.extra-filter-revs` will
      cover the use case for `server.view=immutable` well enough than having to have
      this dedicated configuration. Since `server.view` is not part of any release, I
      would prefer to have it marked as experimental to avoid having it to support it
      for ever.
      08481e11462e
    • Pierre-Yves David's avatar
      repoview: move subsettable in a dedicated module · caebe5e7f4bd
      Pierre-Yves David authored
      The dictionary got moved in `branchmap` to avoid import cycle. However, we are
      about to needs it in repoview too. So we introduce a now module to define that
      that mapping.
      caebe5e7f4bd
  6. Feb 01, 2019
  7. Mar 27, 2019
    • Pierre-Yves David's avatar
      compression: introduce an official `zstd-revlog` requirement · 10a6725dca6e
      Pierre-Yves David authored
      This requirement supersedes `exp-compression-zstd`. However, we keep support for
      the old requirement.
      
      Strictly speaking, we do not need to add a new requirement, there are no logic
      change making "new" repo incompatible with mercurial client using a version
      that support `exp-compression-zstd`.
      
      The choice to introduce a new requirement is motivated by the following:
      
      * The previous requirement was explicitly "experimental". Using it by default
        could confuse users.
      
      * adding support for a hypothetical third compression engine will requires new
        code, and will comes with its own requirement tool.
      
      * We won't use it as the default for a while since I do not think we support
        zstd on all platform. I can imagine we'll gain another (unrelated but on my
        default) requirement by the time we turn this zstd by default.
      10a6725dca6e
  8. Apr 16, 2019
  9. Apr 15, 2019
  10. Apr 16, 2019
  11. Apr 05, 2019
    • Pierre-Yves David's avatar
      pull: improved message issued in case of failed update · a362b0b95e42
      Pierre-Yves David authored
      When running `hg pull --update`, the update step may fail. Nothing in the error
      message help to understand the abort is related to the secondary step (update)
      instead of the primary step (pull).
      
      We now add some information to the error message to clarify it comes from the
      update part. It is useful in various situation (uncommitted changes blocking the
      update, update to hidden destination, etc...)
      
      The pull output is updated from:
      
        $ hg pull ../repo-Bob --rev 956063ac4557 --update
        pulling from ../repo-Bob
        searching for changes
        adding changesets
        adding manifests
        adding file changes
        added 2 changesets with 0 changes to 2 files (+1 heads)
        (2 other changesets obsolete on arrival)
        abort: filtered revision '6'!
      
      to:
      
        $ hg pull ../repo-Bob --rev 956063ac4557 --update
        pulling from ../repo-Bob
        searching for changes
        adding changesets
        adding manifests
        adding file changes
        added 2 changesets with 0 changes to 2 files (+1 heads)
        (2 other changesets obsolete on arrival)
        abort: cannot update to target: filtered revision '6'!
      
      (I am not sure why the actual error, "filtered revision '6'", is not using the
      more modern format mentioning the obsolescence fate of '6')
      a362b0b95e42
    • Pierre-Yves David's avatar
      pull: deal with locally filtered changeset passed into --rev · 232a33a11ce0
      Pierre-Yves David authored
      Nowadays, it is possible to explicitly pull a remote revision that end up being
      hidden locally (eg: obsoleted locally). However before this patch, some
      internal processing where crashing trying to resolve a filtered revision.
      
      Without this patches, the pull output result a confusing output:
      
        $ hg pull ../repo-Bob --rev 956063ac4557
        pulling from ../repo-Bob
        searching for changes
        adding changesets
        adding manifests
        adding file changes
        added 2 changesets with 0 changes to 2 files (+1 heads)
        (2 other changesets obsolete on arrival)
        abort: 00changelog.i@956063ac4557828781733b2d5677a351ce856f59: filtered node!
      232a33a11ce0
  12. Apr 16, 2019
  13. Apr 04, 2019
    • Pierre-Yves David's avatar
      repoview: keep the branchmap cache for the `served.hidden` view warm · 70b71421fd33
      Pierre-Yves David authored
      For the same reason we want to keep the cache for the `served` view up to date,
      we want to also keep the `served.hidden` view up to date. If some processes with
      a readonly access to the repo needs to access it, we better have the cache warm
      to avoid computing the same data over and over and over.
      
      In most case (no secret changesets), the "served" and "served.hidden" set will
      be identical and no cache will actually have to be updated.
      70b71421fd33
  14. May 21, 2018
    • Pierre-Yves David's avatar
      repoview: introduce a filter for serving hidden changesets · ef0e3cc684b3
      Pierre-Yves David authored
      There are multiple usecase for being able to explicitly view or pull obsolete
      from a server. We need to be able to do so without exposing the secret
      changesets. We introduces a dedicated repository "view" to do so. Way to expose
      this "view" to the user will come later.
      
      To keep a behavior consistent with expected client/server behavior, the general
      idea is for the obsolete access to be explicitly requested by the code
      generating the request. In addition, the will be server side configuration to
      restrict the access to this feature.
      ef0e3cc684b3
  15. Apr 13, 2019
  16. Apr 05, 2019
  17. Apr 01, 2019
    • Pulkit Goyal's avatar
      branchcache: lazily validate nodes from the branchmap · 6578654916ae
      Pulkit Goyal authored
      On my personal hg-repository with 365 entries in .hg/cache/branch2, following
      are the numbers for perfbranchmapload.
      
      Before this patch:
      
      ! wall 0.000866 comb 0.000000 user 0.000000 sys 0.000000 (best of 2680)
      ! wall 0.001525 comb 0.000000 user 0.000000 sys 0.000000 (max of 2680)
      ! wall 0.001107 comb 0.001097 user 0.001086 sys 0.000011 (avg of 2680)
      ! wall 0.001104 comb 0.000000 user 0.000000 sys 0.000000 (median of 2680)
      
      With this patch:
      
      ! wall 0.000530 comb 0.000000 user 0.000000 sys 0.000000 (best of 4240)
      ! wall 0.001078 comb 0.000000 user 0.000000 sys 0.000000 (max of 4240)
      ! wall 0.000696 comb 0.000693 user 0.000677 sys 0.000017 (avg of 4240)
      ! wall 0.000690 comb 0.000000 user 0.000000 sys 0.000000 (median of 4240)
      
      On our internal repository with ~20k entries in branchcache, I see improvement
      from 0.125 sec to 0.066 sec which is 47% speed up.
      
      The above are the numbers of perfbranchmapload which shows how much time we
      saved by not validating the nodes. But we need to validate some nodes. Following
      are timings of some mercurial operations which have speed up because of this
      lazy validation of nodes:
      
      No-op `hg update` on our internal repository (Avg on 4 runs):
      
      Before: 0.540 secs
      After: 0.430 secs
      
      Setting a branch name which already exists without --force (Avg of 4 runs):
      
      Before: 0.510 secs
      After: 0.250 secs
      
      I ran the ASV performance suite and was unable to see any improvements except
      there was improvement of perfdirstatewrite() on netbeans which I think was not
      related.
      
      I looked into the commit code, the command which I am trying to speedup, it
      looks like it uses revbranchcache to update the branchcache.
      
      Differential Revision: https://phab.mercurial-scm.org/D6208
      6578654916ae
  18. Mar 19, 2019
  19. Apr 15, 2019
  20. Apr 02, 2019
    • Martin von Zweigbergk's avatar
      copies: move comment about implementation of mergecopies() to end · 967c098eed33
      Martin von Zweigbergk authored
      When you start reading about mergecopies(), you want to know what it
      is, not that there are different implementations depending on config,
      so this patch moves that comment to the end.
      
      By the way, we don't seem to define what "copytracing" is. I'm just
      leaving it that way because I don't know what it is myself. It seems
      to be referred to only on mergecopies() (and not in pathcopies(), for
      example), so maybe "copytracing" is supposed to be exactly what
      mergecopies() does?
      
      Differential Revision: https://phab.mercurial-scm.org/D6235
      967c098eed33
  21. Apr 13, 2019
  22. Mar 25, 2019
  23. Mar 20, 2019
  24. Jan 18, 2019
  25. Mar 31, 2019
  26. Mar 27, 2019
  27. Apr 12, 2019
  28. Apr 06, 2019
Loading