Skip to content
Snippets Groups Projects
  1. Apr 25, 2019
  2. Apr 17, 2019
    • Pulkit Goyal's avatar
      narrow: send specs as bundle2 data instead of param (issue5952) (issue6019) · 280f7a09
      Pulkit Goyal authored
      Before this patch, when ACL is involved, narrowspecs are send as bundle2
      parameter for narrow:spec bundle2 part. The limitation of bundle2 parts are they
      cannot send data larger than 255 bytes. Includes and excludes in narrow are not
      limited by size and they can grow over 255 bytes.
      
      This patch introduces a new mandatory bundle2 part and send narrowspecs as data
      of that. The new bundle2 part is introduced to keep things cleaner and easy to
      distinguish related to backward compatibility.
      The part is mandatory because without server's narrowspec, the local ACL narrow
      repo won't work.
      
      This patch makes clients compatible with servers which have older versions.
      However I left a comment that we should drop the other bundle2 part soon as
      that's broken and people should not rely on that.
      
      I named the new bundle2 part 'Narrow:responsespec' because:
      
      1) Capital 'N' to make it mandatory
      2) 'Narrow:spec' cannot be used because bundle2 enforces that there should not
      be two different parts which resolve to same name when lowercased.
      3) reponsespec clears that they are specs which are send as reponse by the
      server
      
      While I was here, I renamed `narrowhgacl` section to `narrowacl` as suggested by
      idlsoft@ and martinvonz@.
      
      Differential Revision: https://phab.mercurial-scm.org/D6310
      280f7a09
  3. Apr 27, 2019
  4. Apr 24, 2019
    • Pulkit Goyal's avatar
      context: check file exists before getting data from _wrappedctx · 14589f19
      Pulkit Goyal authored
      overlayworkingctx class is used to do in-memory merging. The data() function of
      that class has logic to look for data() in the wrappedctx if the file data in
      cache is empty and if the file is dirty. This assumes that if a file is dirty
      and cache has empty data for it, it will exists in the _wrappedctx.
      
      However this assumption can be False in case when we are merging a file which is
      empty in destination. In these cases, the backup file 'foo.orig' created by our
      internal merge algorithms will be empty, however it won't be present in
      _wrappedctx. This case will lead us to error like the one this patch is fixing.
      
      Let's only fallback to getting data from wrappedctx if cache has 'None' as data.
      
      Differential Revision: https://phab.mercurial-scm.org/D6308
      14589f19
    • Pulkit Goyal's avatar
      tests: show IMM is broken when merging file empty in destination · 81805104
      Pulkit Goyal authored
      When we are doing in-memory merging, and we are merging a file which is empty in
      merge destination, it leads to error 'abort: xxx not found in manifest'.
      
      Next patch will fix this error.
      
      Differential Revision: https://phab.mercurial-scm.org/D6307
      81805104
  5. Apr 19, 2019
  6. Apr 21, 2019
    • Gregory Szorc's avatar
      setup: tweak error message for Python 3 · cd1bede3
      Gregory Szorc authored
      We now have beta support for Python 3. In my opinion, it isn't
      yet stable enough to allow `pip install Mercurial` to work with
      Python 3 out of the box: we don't want people accidentally using
      Mercurial with Python 3 just yet.
      
      But I do think we should be more friendly about informing people
      of their options.
      
      This commit tweaks the error message that users see when running
      setup.py with Python 3. We instruct them about the current level
      of Python 3 support, point them at the wiki for more info, and
      give them instructions on how to bypass the check.
      
      As part of this, I also changed which version value is printed,
      as we were printing a named tuple before.
      cd1bede3
    • Gregory Szorc's avatar
      setup: remove set and dict comprehensions · bd92dd3e
      Gregory Szorc authored
      Yuya observed in a recent review that it is worthwhile to keep
      setup.py parseable with Python 2.6 so a useful error message is
      seen when attempting to run with Python 2.6.
      
      This commit removes a set and dict comprehension so setup.py
      is parseable with Python 2.6.
      bd92dd3e
  7. Apr 19, 2019
  8. Apr 20, 2019
    • Gregory Szorc's avatar
      setup: properly package distutils in py2exe virtualenv builds · 71d8b4d9
      Gregory Szorc authored
      Our in-repo py2exe packaging code uses virtualenvs for managing
      dependencies. An advantage of this is that packaging is more
      deterministic and reproducible. Without virtualenvs, we need to
      install packages in the system Python install. Packages installed
      by other consumers of the system Python could leak into the Mercurial
      package.
      
      A regression from this change was that py2exe packages contained
      the virtualenv's hacked distutils modules instead of the original
      distutils modules. (virtualenv installs a hacked distutils module
      because distutils uses relative path lookups that fail when running
      from a virtualenv.)
      
      This commit introduces a workaround so py2exe packaging uses the
      original distutils modules when running from a virtualenv.
      
      With this change, `import distutils` no longer fails from py2exe
      builds produced from a virtualenv. This fixes the regression.
      Furthermore, we now include all distutils modules. Before, py2exe's
      module finding would only find modules there were explicitly
      referenced in code. So, we now package a complete copy of distutils
      instead of a partial one. This is even better than before.
      
      # no-check-commit foo_bar function name
      71d8b4d9
  9. Apr 17, 2019
  10. Apr 16, 2019
    • Pierre-Yves David's avatar
      debugdiscovery: include the number of heads in all sets · 607a0de9
      Pierre-Yves David authored
      We already displayed information about heads of the common set that are either
      local or remote heads. We now also do so for heads of the common set that are
      both local and remote heads too. This is useful because various step in the
      set discovery algorithm have head specific optimizations.
      607a0de9
    • Pierre-Yves David's avatar
      recover: add a --[no-]verify flag · 013de80b
      Pierre-Yves David authored
      For trivial cases, the cost of the verify run after `hg recover` is getting in
      the way. In addition for very large repositories, the cost is simply too high
      to be paid, making `hg recover` an unusable commands.
      
      We introduce a --verify flag, set by default. If is automatically associated
      with a --no-verify flag that one can use to skip the verify step.
      
      We might consider changing the default behavior in the future. However this is
      out of scope for this series.
      013de80b
  11. Apr 02, 2019
  12. Dec 28, 2017
    • Martin von Zweigbergk's avatar
      changelog: parse copy metadata if available in extras · 5382d8f8
      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
      5382d8f8
    • Martin von Zweigbergk's avatar
      copies: add config option for writing copy metadata to file and/or changset · 0e41f40b
      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
      0e41f40b
  13. Apr 04, 2019
  14. Apr 12, 2019
    • Pierre-Yves David's avatar
      repoview: flag `server.view` as experimental · 08481e11
      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.
      08481e11
    • Pierre-Yves David's avatar
      repoview: move subsettable in a dedicated module · caebe5e7
      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.
      caebe5e7
  15. Feb 01, 2019
  16. Mar 27, 2019
    • Pierre-Yves David's avatar
      compression: introduce an official `zstd-revlog` requirement · 10a6725d
      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.
      10a6725d
  17. Apr 16, 2019
  18. Apr 15, 2019
  19. Apr 16, 2019
  20. Apr 05, 2019
    • Pierre-Yves David's avatar
      pull: improved message issued in case of failed update · a362b0b9
      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')
      a362b0b9
    • Pierre-Yves David's avatar
      pull: deal with locally filtered changeset passed into --rev · 232a33a1
      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!
      232a33a1
  21. Apr 16, 2019
  22. Apr 04, 2019
    • Pierre-Yves David's avatar
      repoview: keep the branchmap cache for the `served.hidden` view warm · 70b71421
      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.
      70b71421
  23. May 21, 2018
    • Pierre-Yves David's avatar
      repoview: introduce a filter for serving hidden changesets · ef0e3cc6
      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.
      ef0e3cc6
  24. Apr 13, 2019
  25. Apr 05, 2019
  26. Apr 01, 2019
    • Pulkit Goyal's avatar
      branchcache: lazily validate nodes from the branchmap · 65786549
      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
      65786549
  27. Mar 19, 2019
Loading