Skip to content
Snippets Groups Projects
  1. Feb 07, 2020
  2. Feb 08, 2020
  3. Jan 31, 2020
  4. Feb 05, 2020
  5. Feb 07, 2020
  6. Feb 06, 2020
  7. Jan 24, 2020
  8. Jan 22, 2020
  9. Dec 13, 2019
  10. Sep 18, 2019
  11. Feb 07, 2020
  12. Jan 24, 2020
  13. Feb 04, 2020
  14. Jan 21, 2020
    • Matt Harbison's avatar
      lfs: enable workers by default · 87167caa
      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
      87167caa
    • Matt Harbison's avatar
      lfs: fix the stall and corruption issue when concurrently uploading blobs · 43eea17a
      Matt Harbison authored
      We've avoided the issue up to this point by gating worker usage with an
      experimental config.  See 10e62d5efa73, and the thread linked there for some of
      the initial diagnosis, but essentially some data was being read from the blob
      before an error occurred and `keepalive` retried, but didn't rewind the file
      pointer.  So the leading data was lost from the blob on the server, and the
      connection stalled, trying to send more data than available.
      
      In trying to recreate this, I was unable to do so uploading from Windows to
      CentOS 7.  But it reproduced every time going from CentOS 7 to another CentOS 7
      over https.
      
      I found recent fixes in the FaceBook repo to address this[1][2].  The commit
      message for the first is:
      
          The KeepAlive HTTP implementation is bugged in it's retry logic, it supports
          reading from a file pointer, but doesn't support rewinding of the seek cursor
          when it performs a retry. So it can happen that an upload fails for whatever
          reason and will then 'hang' on the retry event.
      
          The sequence of events that get triggered are:
           - Upload file A, goes OK. Keep-Alive caches connection.
           - Upload file B, fails due to (for example) failing Keep-Alive, but LFS file
             pointer has been consumed for the upload and fd has been closed.
           - Retry for file B starts, sets the Content-Length properly to the expected
             file size, but since file pointer has been consumed no data will be uploaded,
             causing the server to wait for the uploaded data until either client or
             server reaches a timeout, making it seem as our mercurial process hangs.
      
          This is just a stop-gap measure to prevent this behavior from blocking Mercurial
          (LFS has retry logic). A proper solutions need to be build on top of this
          stop-gap measure: for upload from file pointers, we should support fseek() on
          the interface. Since we expect to consume the whole file always anyways, this
          should be safe. This way we can seek back to the beginning on a retry.
      
      I ported those two patches, and it works.  But I see that `url._sendfile()` does
      a rewind on `httpsendfile` objects[3], so maybe it's better to keep this all in
      one place and avoid a second seek.  We may still want the first FaceBook patch
      as extra protection for this problem in general.  The other two uses of
      `httpsendfile` are in the wire protocol to upload bundles, and to upload
      largefiles.  Neither of these appear to use a worker, and I'm not sure why
      workers seem to trigger this, or if this could have happened without a worker.
      
      Since `httpsendfile` already has a `close()` method, that is dropped.  That
      class also explicitly says there's no `__len__` attribute, so that is removed
      too.  The override for `read()` is necessary to avoid the progressbar usage per
      file.
      
      [1] https://github.com/facebookexperimental/eden/commit/c350d6536d90c044c837abdd3675185644481469
      [2] https://github.com/facebookexperimental/eden/commit/77f0d3fd0415e81b63e317e457af9c55c46103ee
      [3] https://www.mercurial-scm.org/repo/hg/file/5.2.2/mercurial/url.py#l176
      
      Differential Revision: https://phab.mercurial-scm.org/D7962
      43eea17a
    • Matt Harbison's avatar
      lfs: add a method to the local blobstore to convert OIDs to file paths · 06de4a67
      Matt Harbison authored
      This is less ugly than passing an open callback to the `httpsendfile`
      constuctor.
      
      Differential Revision: https://phab.mercurial-scm.org/D7961
      06de4a67
  15. Jan 15, 2020
  16. Feb 05, 2020
  17. Feb 06, 2020
    • Kyle Lippincott's avatar
      py3: fully fix bundlepart.__repr__ to return str not bytes · 74172a23
      Kyle Lippincott authored
      My previous fix did not fully fix the issue: it would attempt to use
      %-formatting to combine two strs into a bytes, which won't work. Let's just
      switch the entire function to operating in strs. This can cause a small output
      difference that will likely not be noticed since no one noticed that the method
      wasn't working at all before: if `id` or `type` are not-None, they'll be shown
      as `b'val'` instead of `val`. Since this is a debugging aid and these strings
      shouldn't be shown to the user, slightly rough output is most likely fine and
      it's likely not worthwhile to add the necessary conditionals to marginally
      improve it.
      
      Differential Revision: https://phab.mercurial-scm.org/D8091
      74172a23
  18. Nov 17, 2019
  19. Nov 16, 2019
  20. Jan 25, 2020
  21. Nov 18, 2019
  22. Nov 16, 2019
  23. Jan 24, 2020
  24. Jan 25, 2020
    • Pierre-Yves David's avatar
      heptapod-ci: add a basic file to be able to run tests with heptapod · 8b1dd3f4
      Pierre-Yves David authored
      Having this yaml file somewhere in the main mercurial repository makes it
      trivial for contributors using heptapod to run CI on their in-progress work.
      There are alot of different combination (python2/python3 pure/cext/rust/pypy)
      to be tested and making sure all of them are covered manually is cumbersome.
      Automatic CI runnig on draft really helps in that matters. We start small bu
      later changesets will add more step testing more of the variants.
      
      The series is targetted on stable to make it available to the widest amount of contribution possible.
      
      The definition of the docker files used for this are available here:
      
          https://dev.heptapod.net/octobus/ci-dockerfiles
      
      Differential Revision: https://phab.mercurial-scm.org/D8011
      8b1dd3f4
  25. Feb 04, 2020
    • Jan Alexander Steffens (heftig)'s avatar
      worker: manually buffer reads from pickle stream · 12491abf
      Jan Alexander Steffens (heftig) authored
      My previous fix (D8051, cb52e619c99e, which added Python's built-in buffering
      to the pickle stream) has the problem that the selector will ignore the buffer.
      When multiple pickled objects are read from the pipe into the buffer at once,
      only one object will be loaded.
      
      This can repeat until the buffer is full and delays the processing of completed
      items until the worker exits, at which point the pipe is always considered
      readable and all remaining items are processed.
      
      This changeset reverts D8051, removing the buffer again. Instead, on Python 3
      only, we use a wrapper to modify the "read" provided to the Unpickler to behave
      more like a buffered read. We never read more bytes from the pipe than the
      Unpickler requests, so the selector behaves as expected.
      
      Also add a test case for "pickle data was truncated" issue.
      
      https://phab.mercurial-scm.org/D8051#119193
      
      Differential Revision: https://phab.mercurial-scm.org/D8076
      12491abf
  26. Jan 02, 2020
  27. Feb 04, 2020
  28. Feb 03, 2020
  29. Feb 04, 2020
  30. Jan 14, 2020
Loading