Skip to content
Snippets Groups Projects
  1. Feb 22, 2025
  2. Oct 25, 2024
  3. Oct 24, 2024
  4. Oct 23, 2024
  5. Oct 02, 2024
    • Matt Harbison's avatar
      tests: use pattern matching to mask `ECONNREFUSED` messages · 73a43fe3e6fd
      Matt Harbison authored
      The second and third one of these in `test-http-proxy.t` was failing on Windows.
      The others were found by grep and by failed tests when output was matched and an
      attempt was made to emit the mask pattern.
      
      The first clonebundles failure on Windows emitted:
      
          error fetching bundle: [WinError 10061] $ECONNREFUSED$
      
      We should probably stringify that better to get rid of the "[WinError 10061]"
      part.
      73a43fe3e6fd
  6. Jun 26, 2023
  7. 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
  8. Jan 31, 2023
  9. Jan 09, 2023
  10. Jan 04, 2023
    • Matt Harbison's avatar
      tests: drop `(py3 !)` output matching predicates · 950c39918bd2
      Matt Harbison authored
      Presumably these were paired with `(no-py3 !)` at one point, but now they were
      unconditionally true.
      
      test-check-code.t required a couple of `(glob)` markers on the changed lines in
      test-lfs-serve-access.t, because of the `$LOCALIP` usage on those lines.  Not
      sure how those lines slipped through the checks previously.
      950c39918bd2
  11. Feb 20, 2022
  12. Mar 04, 2021
  13. Jan 15, 2021
    • Pierre-Yves David's avatar
      clone: make sure we warm the cache after a clone · 95a615dd77bf
      Pierre-Yves David authored
      This work around any deviciency/limitation of the clone process. In our case
      this ensure the persistent nodemap exist with valid content.
      
      Ideally, the cloning process would also do "the right thing". However since
      older server will never be able to do "the right thing". The local workaround
      will be necessary anyway.
      
      I am not worried by the performance impact of this as `hg clone` is non-instant
      on large repositories where is could matters. Warming the cache if they are
      already correct is very fast. And if they are not already warm, this seems like
      a good time to do so.
      
      This impact various test as more cache are now warmed sooner, all the change
      should be harmless.
      
      Differential Revision: https://phab.mercurial-scm.org/D9789
      95a615dd77bf
  14. Dec 10, 2020
  15. Nov 23, 2020
  16. 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
  17. Jan 21, 2020
    • Matt Harbison's avatar
      lfs: enable workers by default · 87167caa2989
      Matt Harbison authored
      With the stall issue seemingly fixed, there's no reason not to use workers.  The
      setting is left for now to keep the test output deterministic, and in case other
      issues come up.  If none do, this can be converted to a developer setting for
      usage with the tests.
      
      Differential Revision: https://phab.mercurial-scm.org/D7963
      87167caa2989
  18. Jan 18, 2020
  19. Jan 15, 2020
  20. Dec 06, 2019
  21. Nov 04, 2019
  22. Oct 06, 2019
  23. Sep 11, 2019
  24. 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
  25. Feb 11, 2019
  26. Feb 07, 2019
    • Mathias De Mare's avatar
      f2f538725d07
    • Matt Harbison's avatar
      lfs: disable all authentication except Basic for HTTP(S) connections · 698667eb7523
      Matt Harbison authored
      I ran into a problem pushing to an old Apache server- the normal outgoing
      traffic occurred, the Batch API request and response occurred, and then things
      suddenly halted.  5 minutes later, a 500 was returned, and the server log had a
      timeout reading 32K from `self._req.bodyfh` in hgweb.request.sendresponse().
      Watching in WireShark, the Batch API got a 401, retried properly, then proceeded
      to PUT the blob (without authentication headers).  This got a 401, but the
      client never retried with authentication.  Worse, the blob was sent over the
      wire in the failed attempt.
      
      This kills digests for both the Batch API and the Transfer API.  While in theory
      we could have the Batch API provide external URLs to a place that supports Basic
      Authentication, the LFS spec actually calls out using Basic Authentication[1].
      It's not clear to me if they've been able to shoehorn in other methods.  But
      let's keep it simple until somebody needs it.
      
      If we only had to support python2, we could just not add the handler for digest
      authentication.  However in python3, AbstractBasicAuthHandler raises ValueError
      if it sees a scheme other than Basic.  So we need to intercept all other schemes
      before it gets to that point.
      
      # no-check-commit because of urllib2.OpenerDirector foo_bar calling conventions
      
      [1] https://github.com/git-lfs/git-lfs/blob/master/docs/api/authentication.md
      698667eb7523
  27. Feb 05, 2019
  28. Jan 28, 2019
    • Matt Harbison's avatar
      py3: conditionalize some LFS test output · 080a5c83914f
      Matt Harbison authored
      I'm not sure why the one stackframe is py2 only, but that seems harmless.  The
      remaining failure is LfsCorruptionError printing the fully qualified name, as
      well as b'' around its message.
      080a5c83914f
  29. Jan 27, 2019
    • Matt Harbison's avatar
      py3: byteify the LFS blobstore module · 02d0a7774882
      Matt Harbison authored
      This is almost entirely b'' prefixing, with a couple of exceptions forced to
      bytes.  Much of this is also borrowed from Augie's code.  There's an
      HTTPError.read() that I flagged that I assume needs to be converted to bytes,
      but I can't find confirmation.
      
      Handling the deserialized JSON object over several functions made r'' vs b''
      accesses confusing, so this assumes that the JSON object will be converted to
      bytes immediately.  That will be done in the following commits, so it's not
      buried in these trivial changes.
      02d0a7774882
    • Matt Harbison's avatar
      py3: add b'' and r'' prefixes to LFS tests · 2a1bb442593b
      Matt Harbison authored
      2a1bb442593b
  30. 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
  31. Dec 10, 2018
    • Boris Feld's avatar
      tests: update network related errors for Debian 9 · 8695fbe17f7c
      Boris Feld authored
      We have a CI job that runs the Mercurial tests in parallel. Some of the
      network related failures seems to be different on the environment. Oddly,
      those failures happens only when running the tests in parallel, not when
      running the test file only.
      
      I have no idea how to get the windows formatted message for the error, if
      someone could give me an hand, I will update this changeset with the value.
      
      Differential Revision: https://phab.mercurial-scm.org/D5401
      8695fbe17f7c
  32. Nov 15, 2018
    • Matt Harbison's avatar
      lfs: make the exception messages consistent · 93e5d18251d6
      Matt Harbison authored
      I don't love that it repeats 'HTTP Error' in an already long message, but I
      doubt that we should assume that it will always say that on the original
      exception message.
      93e5d18251d6
    • Matt Harbison's avatar
      lfs: handle URLErrors to add additional information · 380f5131ee7b
      Matt Harbison authored
      Sometimes the blob server is hit first (e.g. on push), and sometimes it's hit
      last (e.g. pull).  Throw in depth first subrepo operations, and things quickly
      get insane.  It wasn't even mentioning LFS, so just saying "connection refused"
      can be confusing- especially if the blob server is a secondary server and
      connecting to the repo server works.
      
      The exception handler for the transfer handler will print the full path to the
      blob, but that seems fine given that it might be necessary to debug a second
      server.  (We don't yet support a standalone blob server, so the handler for the
      Batch API will cover 99.9% of the current problems.  But it might as well be
      handled now while I'm thinking about it.)
      
      The function for translating to a message was mostly borrowed from
      scmutil.catchall().
      380f5131ee7b
    • Matt Harbison's avatar
      lfs: improve the hints for common errors in the Batch API · 9f78d10742af
      Matt Harbison authored
      The previous message was too debug-ish and less action oriented than a hint
      should be.  The remaining errors that aren't handled are more along the lines of
      programming errors (not using POST, bad accept type, etc), so I'm not bothering
      with that.
      
      The friendly errors purposely use `self.baseurl` instead of the full Batch API
      endpoint because I'd expect some copy/paste/modify on the part of the user here,
      and it would be more confusing if '/objects/batch' magically appeared, but
      shouldn't be used in the config setting.  It still seems like the right thing
      for debugging in the catchall case.
      9f78d10742af
    • Matt Harbison's avatar
      lfs: provide more Batch API error info via a hint in the raised exception · 8863f08c1630
      Matt Harbison authored
      A coworker had a typo in `lfs.url`, forgot it was even set because usually the
      blob server is inferred, and then got a 404.  It would have been easier to debug
      with the failing URL printed.
      8863f08c1630
  33. Sep 21, 2018
    • Matt Harbison's avatar
      lfs: autoload the extension when cloning from repo with lfs enabled · 6637b079ae45
      Matt Harbison authored
      This is based on a patch by Gregory Szorc.  I made small adjustments to
      clean up the messaging when the server has the extension enabled, but the
      client has it disabled (to prevent autoloading).  Additionally, I added
      a second server capability to distinguish between the server having the
      extension enabled, and the server having LFS commits.  This helps prevent
      unnecessary requirement propagation- the client shouldn't add a requirement
      that the server doesn't have, just because the server had the extension
      loaded.  The TODO I had about advertising a capability when the server can
      natively serve up blobs isn't relevant anymore (we've had 2 releases that
      support this), so I dropped it.
      
      Currently, we lazily add the "lfs" requirement to a repo when we first
      encounter LFS data. Due to a pretxnchangegroup hook that looks for LFS
      data, this can happen at the end of clone.
      
      Now that we have more control over how repositories are created, we can
      do better.
      
      This commit adds a repo creation option to add the "lfs" requirement.
      hg.clone() sets this creation option if the remote peer is advertising
      lfs usage (as opposed to just support needed to push).
      
      So, what this change effectively does is have cloned repos
      automatically inherit the "lfs" requirement.
      
      Differential Revision: https://phab.mercurial-scm.org/D5130
      6637b079ae45
  34. Oct 01, 2018
    • Gregory Szorc's avatar
      httppeer: report http statistics · 393e44324037
      Gregory Szorc authored
      Now that keepalive.py records HTTP request count and the
      number of bytes sent and received as part of performing those
      requests, we can easily print a report on the activity when
      closing a peer instance!
      
      Exact byte counts are globbed in tests because they are influenced
      by non-deterministic things, such as hostnames and port numbers.
      Plus, the exact byte count isn't too important anyway.
      
      I feel obliged to note that printing the byte count could have
      security implications. e.g. if sending a password via HTTP basic
      auth, the length of that password will influence the byte count
      and the reporting of the byte count could be a side-channel leak
      of the password length. I /think/ this is beyond our threshold
      for concern. But if we think it poses a problem, we can teach the
      byte count logging code to e.g. ignore sensitive HTTP request
      headers. We could also consider not reporting the byte count of
      request headers altogether. But since the wire protocol uses HTTP
      headers for sending command arguments, it is kind of important to
      report their size.
      
      Differential Revision: https://phab.mercurial-scm.org/D4858
      393e44324037
Loading