Skip to content
Snippets Groups Projects
  1. 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
  2. Feb 01, 2019
  3. 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
  4. Apr 16, 2019
  5. Apr 15, 2019
  6. Apr 16, 2019
  7. 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
  8. Apr 16, 2019
  9. 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
  10. 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
  11. Apr 13, 2019
  12. Apr 05, 2019
  13. 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
  14. Mar 19, 2019
  15. Apr 15, 2019
  16. 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
  17. Apr 13, 2019
  18. Mar 25, 2019
  19. Mar 20, 2019
  20. Jan 18, 2019
  21. Mar 31, 2019
  22. Mar 27, 2019
  23. Apr 12, 2019
  24. Apr 06, 2019
  25. Apr 05, 2019
  26. Apr 11, 2019
    • Georges Racinet's avatar
      discovery: stop direct use of attribute of partialdiscovery · 362726923ba3
      Georges Racinet authored
      Instead of accessing `undecided` directly for ui display purposes,
      we introduce a `stats()` method that could be extended in the future with
      more interesting information.
      
      This is in preparation for a forthcoming Rust version of this object.
      Indeed, attributes and furthermore properties are a bit complicated for
      classes in native code.
      
      We could go further and rename `undecided` to mark it private, but `_undecided`
      is already taken as support for `_undecided` lazyness.
      362726923ba3
    • Martin von Zweigbergk's avatar
      overlayworkingctx: remove misleading trailing slash from directory pattern · 976f069e0ad6
      Martin von Zweigbergk authored
      The paths passed into the matcher are normalized (this applies to
      include patterns and regular patterns, and to both glob kind and path
      kind), so the regex for input "foo/" ended up being "foo(?:/|$)".
      
      Once we have a (recursive) pattern kind only for directories, we could
      switch to that here and remove the "mfiles[0] == path" check. Until
      then, let's at least make it not misleading.
      
      Differential Revision: https://phab.mercurial-scm.org/D6224
      976f069e0ad6
    • Martin von Zweigbergk's avatar
      overlayworkingctx: fix file/dir audit to be repo-relative · f4b1f5537d4c
      Martin von Zweigbergk authored
      Before this patch, test-rebase-inmemory.t would stop erroring out
      about the conflict if you added a "cd a" before line 252. That was
      because a glob matcher (which are relative) was unintentionally
      used. That happened because the matcher was given "include" patterns
      (not regular patterns), and "include" patterns are always glob by
      default (i.e. unless you write them including the kind prefix). IOW,
      the "default='path'" argument passed to ctx.match() was ignored.
      
      Differential Revision: https://phab.mercurial-scm.org/D6223
      f4b1f5537d4c
  27. Apr 10, 2019
Loading