Skip to content
Snippets Groups Projects
  1. Nov 01, 2018
  2. Dec 03, 2018
  3. Dec 04, 2018
  4. Dec 03, 2018
  5. Dec 01, 2018
    • Martin von Zweigbergk's avatar
      rebase: preserve working copy when redoing in-mem rebase on disk · f07d4f94
      Martin von Zweigbergk authored
      When in-memory rebase runs into conflicts, we retry it on disk. But
      before we do that, we abort the in-memory rebase. That is done because
      even though it's mostly in memory, there are still a few state files
      written (e.g. the merge state). We should make it not write those
      files so we don't need to abort, but for the stable branch, let's
      explicitly clear the state we need to clear instead of running the
      usual abort code.
      
      Differential Revision: https://phab.mercurial-scm.org/D5356
      f07d4f94
  6. Nov 30, 2018
  7. Dec 03, 2018
  8. Nov 14, 2018
  9. Nov 29, 2018
  10. Nov 28, 2018
    • Gregory Szorc's avatar
      wireprotov2peer: wait for initial object before resolving future · 15a64330
      Gregory Szorc authored
      As part of rolling out wireprotov2 with redirect support, I
      encountered an edge case with regards to future resolution.
      
      Essentially, the initial response frame from the server did not
      fully decode the initial CBOR object. The frame wasn't marked as
      EOS. In the previous code, we resolved the future for the request
      to response.objects(), which mapped to the commandresponse instance
      which would eventually produce a redirect. Upon receiving
      subsequent data, the initial CBOR object containing the redirect
      would be decoded and we'd process the redirect. However, the
      future would already have been resolved with the initial
      commandresponse.objects() and the client iterating over the
      objects wouldn't receive any objects from the redirect because
      the redirect was populating a different commandresponse instance!
      
      This commit changes the logic so we don't resolve futures until
      the initial CBOR response object is fully decoded or until EOS
      occurs. In cases where there is an empty or partial frame
      associated with a redirect, the future will now resolve with the
      commandresponse containing the proper series of decoded objects.
      15a64330
    • Gregory Szorc's avatar
      wireprotov2peer: always return a bool from _processredirect() · 94b0d0f9
      Gregory Szorc authored
      Without this, we may stop servicing the redirect response if the
      future has already been resolved. And the future will often be
      resolved very early, since many consumers iterate the decoded
      CBOR object stream and expect data to lazily arrive.
      94b0d0f9
  11. Nov 20, 2018
  12. Nov 15, 2018
    • Boris Feld's avatar
      checkexec: create destination directory if necessary · bd087497
      Boris Feld authored
      Since 460733327640, a "share" use the cache of the source repository. A side
      effect is that no `.hg/cache` directory exists in the "share" anymore. As a
      result, the checkexec logic can't use it to create its temporary file and have
      to use the working copy for that.
      
      This is suboptimal, it pollutes the working copy and prevents them to keep the
      file around in cache. We do not want to use the cache directory for the share
      target, it might be on a different file system.
      
      So instead, we (try to) create the directory if it is missing. This is a
      simple change that fixes the current behavior regression on stable.
      
      On default, we should probably ensure the proper directories are created when
      initializing the repository. We should also introduce a 'wcache' directory to
      hold cache file related to the working copy. This would clarify the cache
      situation regarding shares.
      
      The tests catch a couple of other affected cases.
      bd087497
    • Yuya Nishihara's avatar
      graft: do not try to skip rev derived from ancestor more than once (issue6024) · 3bc2e550
      Yuya Nishihara authored
      We check 'x in revs' in other cases, so let's do the same.
      
      The test case credits to Tom Prince.
      3bc2e550
  13. Nov 16, 2018
    • Matt Harbison's avatar
      subrepo: print the status line before creating the peer for better diagnostics · 69d4c8c5
      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.
      69d4c8c5
  14. Nov 14, 2018
  15. Nov 11, 2018
  16. Nov 09, 2018
    • Gregory Szorc's avatar
      hgweb: cast bytearray to bytes · 6107d454
      Gregory Szorc authored
      PEP-3333 seems to indicate that bytes is the only allowed type that can
      be used to express the output of a WSGI application. And some WSGI
      environments seem to enforce this (mod_wsgi does).
      
      This commit universally casts bytearray instances to bytes to appease
      the WSGI specification.
      
      I found this because wireprotov2 is emitting bytearray instances. I'd
      like to keep things that way because the way it builds a data
      structure, bytearray is more efficient. I'd rather keep the low-level
      code efficient (and using bytearray) and cast at the edges than impose
      a performance penalty on code that may run outside WSGI contexts.
      6107d454
    • Matt Harbison's avatar
  17. Nov 05, 2018
  18. Nov 02, 2018
  19. Oct 28, 2018
  20. Nov 02, 2018
  21. Oct 19, 2018
    • Anton Shestakov's avatar
      relnotes: various tweaks for release notes · 683e99f0
      Anton Shestakov authored
      Stop filtering out commits that are expected to be covered by releasenotes
      extension: now we want two lists, one for WhatsNew and one for ReleaseX.Y.
      
      Use `only(stoprev, startrev)` to make `relnotes -h` output be actually true
      about what revisions are included.
      
      More filter rules, mostly obvious.
      
      More classifying rules to have less things in "unsorted".
      
      Looks like nargs=1 was just making args.startrev and args.stoprev be lists for
      no reason.
      
      BC and API sections are renamed to what we're using on the WhatsNew page, and
      also just skipped if empty.
      683e99f0
  22. Nov 01, 2018
  23. Oct 31, 2018
    • Paul Morelle's avatar
      setup: explain to distutils how we write rc versions · b6bc2293
      Paul Morelle authored
      When we use a rc version number (e.g. 4.8rc0), bdist_msi is using
      distutils.StrictVersion to parse it into a tuple of numbers.
      By default, StrictVersion.version_re only recognizes [ab] for alpha/beta,
      where mercurial may use '-rc' or 'rc'.
      This change makes StrictVersion parse correctly our version numbers, so that
      bdist_msi doesn't fail on rc versions.
      b6bc2293
    • Boris Feld's avatar
      changegroup: restore default node ordering (issue6001) · 634b4531
      Boris Feld authored
      Changeset db5501d93bcf changed the default node ordering from "storage" to
      "linearize".
      
      While the new API is more explicit and cleaner, the "linearize" order is
      problematic on certain repositories like netbeans where it makes bundling
      slower the more nodes we bundle.
      
      Pushing and pulling 100 changesets was ~20% slower and pushing and pulling
      1000 changesets was ~600% slower.
      
      A very quick analysis of profile traces showed that the pull operation was
      taking more time creating the delta.
      
      Putting back the old default order seems to be the safe option. With more time
      during the next cycle, we can understand better the impact of sorting with the
      DAG order by default, the source of the regression and how to mitigate it.
      
      /!\ We are still waiting for the full performance impact but with this patch,
      bundling and pulling locally (not on the performance workstation) 1000
      changesets on the netbeans repository is as fast as before the regression.
      
      Differential Revision: https://phab.mercurial-scm.org/D5196
      634b4531
  24. Oct 29, 2018
Loading