Skip to content
Snippets Groups Projects
  1. Feb 22, 2025
  2. Nov 28, 2024
  3. Dec 11, 2023
    • Pierre-Yves David's avatar
      changelog: never inline changelog · dcaa2df1f688
      Pierre-Yves David authored
      The test suite mostly use small repositories, that implies that most changelog in the
      tests are inlined. As a result, non-inlined changelog are quite poorly tested.
      Since non-inline changelog are most common case for serious repositories, this
      lack of testing is a significant problem that results in high profile issue like
      the one recently fixed by 66417f55ea33 and 849745d7da89.
      
      Inlining the changelog does not bring much to the table, the number of total
      file saved is negligible, and the changelog will be read by most operation
      anyway.
      
      So this changeset is make it so we never inline the changelog, and de-inline the
      one that are still inlined whenever we touch them.
      
      By doing that, we remove the "dual code path" situation for writing new entry to
      the changelog and move to a "single code path" situation. Having a single
      code path simplify the code and make sure it is covered by test (if test cover
      that situation obviously)
      
      
      This impact all tests that care about the number of file and the exchange size,
      but there is nothing too complicated in them just a lot of churn.
      
      The churn is made "worse" by the fact rust will use the persistent nodemap on
      any changelog now. Which is overall a win as it means testing the persistent
      nodemap more and having less special cases.
      
      In short, having inline changelog is mostly useless and an endless source of
      pain. We get rid of it.
      dcaa2df1f688
  4. Feb 28, 2023
    • Matt Harbison's avatar
      configitems: enable changegroup3 by default (unless using infinitepush) · 2cf264e9aa75
      Matt Harbison authored
      The LFS extension requires this, and if it isn't enabled on the client (or the
      LFS extension isn't loaded), a web client gets a 500 instead of a sensible error
      message.  Now it gets a different (client) error, but maybe it can be handled
      more gracefully.  c0f11347b107 indicates that treemanifest repos have this issue
      too.  29cfc474c5fd mentions gating this behind `experimental` so that the format
      could change, but that was 7 years ago and we now have an experimental
      `changegroup4` as well.
      
      We can keep this as a config for the next cycle in case someone runs into an
      unexpected problem, and then jettison it if the infinitepush bundle name changes
      are either acceptable as-is or can be created differently.
      2cf264e9aa75
  5. May 02, 2022
  6. Jan 24, 2022
    • Pierre-Yves David's avatar
      stream-clone: filter possible missing requirements using all supported one · 6d2ddea0721a
      Pierre-Yves David authored
      The `supportedformat` requirements is missing some important requirements and it
      seems better to filter out with all requirements we know, not just an
      "arbitrary" subset.
      
      The `supportedformat` set is lacking some important requirements (for example
      `revlog-compression-zstd`). This is getting fixed on default (for Mercurial 6.1)
      
      However, fixing that in 6.1 means the stream requirements sent over the wire
      will contains more items. And if we don't apply this fix on older version, they
      might end up complaining about lacking support for feature they actually support
      for years.
      
      This patch does not fix the deeper problem (advertised stream requirement
      lacking some of them), but focus on the trivial part : Lets use the full set of
      supported requirement for looking for unsupported ones.
      
      This patch should be simple to backport to older version of Mercurial and
      packager should be encouraged to do so.
      
      This is a graft of d9017df70135 from default.
      
      Differential Revision: https://phab.mercurial-scm.org/D12091
      6d2ddea0721a
  7. May 20, 2021
  8. Apr 19, 2021
  9. Apr 06, 2021
  10. Mar 10, 2021
  11. Feb 15, 2021
  12. Mar 04, 2021
  13. Oct 22, 2020
  14. Oct 23, 2020
    • Yuya Nishihara's avatar
      url: do not continue HTTP authentication with user=None (issue6425) · ff48eea4a926
      Yuya Nishihara authored
      I initially thought this is a py3-compat bug of passwordmgr._writedebug(),
      but actually returning (None, str) pair is wrong at all. HTTP authentication
      would continue with user="None" in that case.
      
      Since registering a password of user=None should also be wrong, this patch
      simply adds early return.
      ff48eea4a926
  15. 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
  16. Sep 11, 2019
  17. Sep 08, 2019
    • Pierre-Yves David's avatar
      changegroup: move message about added changes to transaction summary · d7304434390f
      Pierre-Yves David authored
      Before that, applying multiple changegroups in the same transaction issued the
      message multiple time. This result in a confusing output:
      
          adding changesets
          adding manifests
          adding file changes
          added 32768 changesets with 60829 changes to 2668 files
          adding changesets
          adding manifests
          adding file changes
          added 8192 changesets with 16885 changes to 1553 files
          adding changesets
          adding manifests
          adding file changes
          added 1020 changesets with 1799 changes to 536 files
          adding changesets
          adding manifests
          ...
      
      Instead, we now only issue the message once at the end of the transaction,
      summing up all added changesets, changes and files. The line is identical, but
      happens sightly later in the output.
      
      There are other suboptimal behavior around issue multiple changegroup (eg:
      progress bar). We'll cover them later.
      
      This impact of lot of test as one would expect, but a two pass check show they
      are just the order change we expected.
      
      To deal with "under the hood" bundle application by internal code, we had to
      take a slightly hacky move. We could clean that up with a more official way to
      enter "under the hood" section, however I want to keep this series simple to get
      it landed. This kind of change have a very high bit rot rate since it impact a
      lot of test output.
      d7304434390f
  18. Feb 09, 2019
    • Pierre-Yves David's avatar
      transaction: include txnname in the hookargs dictionary · 94faa2e84094
      Pierre-Yves David authored
      There is no reason to not include the txnname alongside the txnid in all case.
      The python hooks already have them, so aligning the the shell hooks seems it
      could be useful in the future.
      
      (I don't have a strong opinion about this, we can also decide to never align the
      python and shell hooks and this and I'll drop this patch).
      94faa2e84094
  19. Feb 05, 2019
    • Matt Harbison's avatar
      py3: ensure the HTTP password manager returns strings, not bytes · 349c8879becd
      Matt Harbison authored
      The digest handler calls into the password manager on its own, and it apparently
      expects strings.  Perhaps the Basic authentication handler didn't hit this
      because of its manual password fetch and format in retry_http_basic_auth().
      
      The `pycompat.bytesurl()` on the user and password just above the first url.py
      diff seems unnecessary, because the password proxy in ui is converting to bytes
      IIUC.
      349c8879becd
    • Matt Harbison's avatar
      tests: enable HTTP digest testing · 46432c04f010
      Matt Harbison authored
      I suppose we could spin the client side extension off to a *.py file if it gets
      more use.  I was basically just looking to avoid killing the server and
      relaunching it just to change authentication schemes, because that doesn't
      always work on Windows.
      
      The test changes capture the problem with py3.
      46432c04f010
    • Matt Harbison's avatar
      tests: extract the http server authentication extension to a single module · 549af2fa089f
      Matt Harbison authored
      We had 4 copy/pastes of this, and no coverage for http digests (which are
      currently broken on py3).
      549af2fa089f
  20. Dec 28, 2018
    • Matt Harbison's avatar
      extensions: deprecate extsetup without a `ui` argument (API) · 28a4fb793ba1
      Matt Harbison authored
      9.5 years should be enough time, but there were some tests for the old style
      still (which are now updated).  Exthelper doesn't fallback to the old API, so
      this is for consistency.
      
      .. api::
      
         The extension hook ``extsetup`` without a `ui` argument has been deprecated,
         and will be removed in the next version.  Add a `ui` argument to avoid the
         deprecation warning.
      28a4fb793ba1
  21. Dec 19, 2018
  22. Nov 16, 2018
    • Matt Harbison's avatar
      subrepo: print the status line before creating the peer for better diagnostics · 69d4c8c5c25e
      Matt Harbison authored
      I ran into a problem where I tried updating to a different branch, and the
      process appeared to hang.  It turned out that the subrepo revision wasn't
      available locally, and I must have originally cloned it from an `hg serve -S` on
      a machine that currently wasn't serving anything.  It took 2+ minutes to
      timeout, and didn't mention what it was connecting to even then.
      
      There are a couple of other issues in this scenario too.
      
        - The repo is dirty after the failed checkout because the top level repo is
          updated first.  We should probably make 2 passes- top down to pull
          everything needed, and then do an update once everything is in place.
      
        - Something must be reading .hgsubstate from wdir because if the same merge
          command is run after the timeout, a prompt is issued that the local and
          remote subrepo diverged, instead of hanging.  But it lists the local version
          and remote version as having the same hash.
      69d4c8c5c25e
  23. Sep 17, 2018
    • Anton Shestakov's avatar
      bundle2: make server.bundle2.stream default to True · 4bd6e444c76f
      Anton Shestakov authored
      Support for bundle2 streaming clones has been shipped in Mercurial 4.5
      (7eedbd5d4880), but was never activated by default. It's time to have more
      people use it. The new format allows streaming clones to transport cache
      (hooray for speed) and phaseroots (fixes phase-related issues).
      
      Changes in tests:
      
      bundle2 capabilities now have "stream=v2" (plus a '\n' as a separator) and
      therefore take 14 bytes more: "%0Astream%3Dv2". Tip for tests that have data
      encoded with CBOR: 0xd3 - 0xc5 = 14.
      
      $USUAL_BUNDLE2_CAPS$ replaces $USUAL_BUNDLE2_CAPS_SERVER$, which is the same
      thing, but without "stream=v2".
      
      Since streaming clones now also transfer caches, the reported byte and file
      counts are higher (e.g. 816 bytes in 9 files instead of 613 bytes in 4 files,
      a bit of --debug and manual math confirms that the caches take these extra 203
      bytes in 5 files).
      
      Differential Revision: https://phab.mercurial-scm.org/D4680
      4bd6e444c76f
  24. Sep 04, 2018
  25. Aug 18, 2018
    • Matt Harbison's avatar
      clone: allow local cloning to create more than one level of directories · 143efea71c2a
      Matt Harbison authored
      I figure cloning a remote repository is more common, thus it's more likely that
      some people might be relying on the less restrictive behavior.  Additionally,
      `hg init` will also create more than one level of missing directories.
      
      I also have a use case for reading the subrepos from .hgsub, and sharing them
      into the normal nested location on the server.  SCM Manager doesn't host
      subrepos in the normal nested location, which is nice for deduplicating the
      repository data, but confuses `hg verify`.  Some of the subrepos are in the root
      of the repositories, while others are one or two directories deep.  So not
      having to build up the parent path first is desirable.
      143efea71c2a
    • Matt Harbison's avatar
      tests: demonstrate an inconsistency when cloning to a missing directory tree · 8724de878268
      Matt Harbison authored
      I noticed that `hg share` is unable to create more than one missing directory on
      the path, and thought it was inconsistent with clone.  It turns out that the
      path for copying/linking the remote store has the same limitation, but cloning
      from a remote repo doesn't.
      8724de878268
  26. May 01, 2018
  27. Apr 14, 2018
  28. Apr 12, 2018
  29. Apr 11, 2018
  30. Jan 18, 2018
    • Jörg Sonnenberger's avatar
      wireproto: support for pullbundles · aacfca6f9767
      Jörg Sonnenberger authored
      Pullbundles are similar to clonebundles, but served as normal inline
      bundle streams. They are almost transparent to the client -- the only
      visible effect is that the client might get less changes than what it
      asked for, i.e. not all requested head revisions are provided.
      
      The client announces support for the necessary retries with the
      partial-pull capability. After receiving a partial bundle, it updates
      the set of revisions shared with the server and drops all now-known
      heads from the request list. It will then rerun getbundle until
      no changes are received or all remote heads are present.
      
      Extend badserverext to support per-socket limit, i.e. don't assume that
      the same limits should be applied to all sockets.
      
      Differential Revision: https://phab.mercurial-scm.org/D1856
      aacfca6f9767
  31. Apr 04, 2018
  32. Apr 03, 2018
  33. Jan 18, 2018
    • Boris Feld's avatar
      revbranchcache: advertise and use 'rbc' exchange capability · 2090044a288d
      Boris Feld authored
      The feature is now advertised and use.
      
      Updating the branchmap cache can be very expensive (up to minutes on large
      repository) and fetching revision branch data is about 80% of that. Exchanging
      the rev branch cache over the wire really help to recover from branch map
      invalidation.
      
      (There is a good chance other in flight chance would conflict on
      test-http-bad-server.t and other. So here is a small note to help update that
      test again: capabilities=19bytes, part-107bytes)
      2090044a288d
  34. Mar 05, 2018
  35. Mar 11, 2018
  36. Feb 21, 2018
    • Gregory Szorc's avatar
      wireproto: declare operation type for most commands (BC) (SEC) · e3c228b4510d
      Gregory Szorc authored
      The permissions model of hgweb relies on a dictionary to declare
      the operation associated with each command - either "pull" or
      "push." This dictionary was established by d3147b4e3e8a in 2008.
      Unfortunately, we neglected to update this dictionary as new
      wire protocol commands were introduced.
      
      This commit defines the operations of most wire protocol commands
      in the permissions dictionary. The "batch" command is omitted because
      it is special and requires a more complex solution.
      
      Since permissions checking is skipped unless a command has an entry in
      this dictionary (this security issue will be addressed in a subsequent
      commit), the practical effect of this change is that various wire
      protocol commands now HTTP 401 if web.deny_read or web.allow-pull,
      etc are set to deny access. This is reflected by test changes. Note
      how various `hg pull` and `hg push` operations now fail before
      discovery. (They fail during the initial "capabilities" request.)
      
      This change fixes a security issue where built-in wire protocol
      commands would return repository data even if the web config were
      configured to deny access to that data.
      
      I'm on the fence as to whether we should HTTP 401 the capabilities
      request. On one hand, it can expose repository metadata and can tell
      callers things like what version of Mercurial the server is running.
      On the other hand, a client may need to know the capabilities in order
      to authenticate in a follow-up request. It appears that Mercurial
      clients handle the HTTP 401 on *any* protocol request, so we should
      be OK sending a 401 for "capabilities." But if this causes problems,
      it should be possible to allow "capabilities" to always work.
      
      .. bc::
      
         Various read-only wire protocol commands now return HTTP 401
         Unauthorized if the hgweb configuration denies read/pull access to
         the repository.
      
         Previously, various wire protocol commands would still work and
         return data if read access was disabled.
      e3c228b4510d
  37. Jan 22, 2018
    • Gregory Szorc's avatar
      bundle2: always advertise client support for stream parts · 1d118f9f4f57
      Gregory Szorc authored
      Previously, enabling of stream clone over bundle2 was a server-side
      only change. And clients would only advertise bundle2 support for
      stream clones if an experimental config option was set.
      
      This situation wasn't forward compatible because in the future
      (when the feature is enabled on servers by default), an old client
      would send a request to the server but it wouldn't send its own
      bundle2 capability support for stream parts. Servers would have to
      infer that clients not sending this capability were old Mercurial
      clients that only sent the capability if the feature was
      explicitly enabled. Implicit and inferred behavior makes implementing
      servers hard. It's much better to be explicit about client features.
      
      We should either make the config option for bundle2 stream clones
      disable the feature client-side as well (so a server doesn't see
      a request from a client not advertising stream support). Or we
      should always advertise stream support if a client is willing
      to accept stream parts.
      
      Since I anticipating stabilizing stream clone support in bundle2
      quickly, I think it's safe to always advertise client support
      in the bundle2 capabilities. So this commit changes things to
      do that.
      
      Because capabilities now vary between client and server, we had
      to create variations of the variable substitutions for those
      strings.
      
      Differential Revision: https://phab.mercurial-scm.org/D1931
      1d118f9f4f57
Loading