Skip to content
Snippets Groups Projects
  1. Mar 18, 2018
  2. Mar 11, 2018
  3. Mar 15, 2018
    • Martin von Zweigbergk's avatar
      rebase: allow in-memory merge of the working copy parent · 795eb53f
      Martin von Zweigbergk authored
      Before this patch and when the rebase involved the working copy parent
      (and thus the working copy too), we would not do in-memory rebase even
      if requested to. The in-code comment explains that the reason had
      something to do with avoiding an extra update, but I don't know which
      update that refers to. Perhaps an earlier version of the code used to
      update to the destination before rebasing even if in-memory rebase was
      requested? That seems to not be done at least since aa660c1203a9
      (rebase: do not bail on uncomitted changes if rebasing in-memory,
      2017-12-07).
      
      To see if this still made it slower, I create a single tiny commit on
      top of one branch of the mozilla-unified repo (commit a1098c82 to be
      exact) and rebased it to another branch (commit d4e9a7be). Before this
      patch that took 11.8s and after this patch it took 8.6s (I only did
      two runs each, but the timings were very consistent).
      
      Differential Revision: https://phab.mercurial-scm.org/D2876
      795eb53f
  4. Mar 17, 2018
  5. Mar 14, 2018
    • Martin von Zweigbergk's avatar
      uncommit: leave empty commit if all files are uncommitted · 28ba7d11
      Martin von Zweigbergk authored
      We had instructions for our internal users to add copy information
      after commit like this:
      
        hg uncommit <srcfile> <dstfile>
        hg cp --after <srcfile> <dstfile>
        hg amend
      
      That usually works, but if the rename was the only change in that
      commit, then the commit would get pruned. It's easy to fix the recipe:
      just pass the --keep option. However, it seems too subtle, so I think
      this is an indication that the commit should not be pruned if any
      patterns were given.
      
      Differential Revision: https://phab.mercurial-scm.org/D2862
      28ba7d11
  6. Mar 16, 2018
  7. Mar 15, 2018
  8. Jan 18, 2018
    • Boris Feld's avatar
      revbranchcache: advertise and use 'rbc' exchange capability · 2090044a
      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)
      2090044a
  9. Feb 21, 2018
    • Boris Feld's avatar
      bundle: include advisory rev branch cache part in bundle2 bundle · b89a7ef2
      Boris Feld authored
      `hg bundle` command producing bundle2 will now include an optional part
      containing the revision-branch cache data.
      
      The data sent are mostly nodes so it is quite compact.  The goal of the
      rev-branch-cache is to speed up branch map computation, especially when the
      branchmap gets invalidated so we send data for all exchanged changesets. In
      addition, computing the relevant heads to send in case of partial pulling would
      be challenging.
      
      As a reminder, the rev branch cache data significantly speed up branch
      computation. Having it around provides a small speedup to pull/clone and much
      higher tolerance to branch map cache invalidation that might happens from later
      commands.
      
      On the Mercurial repository, computing the visible branchmap from scratch move
      from 2.00 seconds to 0.34s (a -83% speedup).
      
      Using this new part, Unbundling the full Mercurial repository moves from 25.736
      seconds to 24.030 seconds (around -7% speedup). The bundle size increase is
      around 3% (from 22.43 MB to 23.13MB)
      
      
      On an half a million revision repository with twenty thousand
      branches, computing the branchmap moves from 75 seconds to 45 second (-40%) if
      the caches is used.
      
      A bundle containing 50 000 changesets in such repository get a 0.5% size
      increase from such part for a -3% unbundling time speedup.
      b89a7ef2
  10. Feb 26, 2018
  11. Feb 21, 2018
  12. Mar 14, 2018
  13. Mar 05, 2018
  14. Mar 14, 2018
  15. Mar 13, 2018
  16. Mar 10, 2018
  17. Mar 12, 2018
  18. Mar 08, 2018
  19. Mar 09, 2018
    • Martin von Zweigbergk's avatar
      rebase: also include commit of collapsed commits in single transaction · 17a744c5
      Martin von Zweigbergk authored
      When rebase.singletransaction is set, we still used to create a second
      transaction when committing with --collapse. It's simpler to create a
      single transaction.
      
      Note that in the affected .t file, the test that uses --collapse still
      appears to create two transactions (it prints "rebase status stored"
      twice). However, only a single transaction is actually created and the
      second printout comes from cmdutil.commitforceeditor() that explicitly
      calls tr.writepending().
      
      Also note the that we now roll back any commits if the user closes the
      commit message editor with an error code (or leaves the message
      empty). That might be unfortunate, but it's consistent with how we
      behave in the --no-collapse case (if the user passed --edit). If we
      want to change that, I think it should be done consistently in a
      separate patch.
      
      Differential Revision: https://phab.mercurial-scm.org/D2728
      17a744c5
  20. Mar 13, 2018
    • Matt Harbison's avatar
      lfs: debug print HTTP headers and JSON payload received from the server · 0dcf50dc
      Matt Harbison authored
      This has been extremely valuable to show divergences between `hg serve` and
      `lfs-test-server`.  Once the `hg serve` code lands, there will be a certain
      amount of conditionalizing that needs to be done, because `lfs-test-server`
      doesn't always follow its spec.
      
      The $ISO_8601_DATE_TIME$ pattern masks the fact that `lfs-test-serve` is sending
      out an expires_at value of "0001-01-01T00:00:00Z".  `hg serve` will (probably)
      use current time + 10 minutes or similar.  The $HTTP_DATE$ is the current time.
      0dcf50dc
    • Matt Harbison's avatar
      test-lfs: dial up the debugging on commands that interact with the server · 24e6342d
      Matt Harbison authored
      This will be useful to let the client print out the HTTP headers and JSON in a
      future patch, so we can compare native LFS serving against test-lfs-server
      behavior.  There tends to be a lot of debug stuff that we don't care about here
      in a push, so I was tempted to print this output with a [devel] config.  But
      this will be useful for field debugging too, so just put up with the extra
      output here.
      
      It would have been nice to be able to set ui.debug once, but issue5815 prevents
      that.
      24e6342d
  21. Feb 24, 2018
  22. Mar 08, 2018
  23. Feb 28, 2018
  24. Mar 11, 2018
    • Gregory Szorc's avatar
      hgweb: remove wsgirequest (API) · f0a85154
      Gregory Szorc authored
      Good riddance.
      
      .. api::
      
         The old ``wsgirequest`` class for handling everything WSGI in hgweb
         has been replaced by separate request and response types. Various
         high-level functions in the hgweb WSGI applications now receive
         these new types as arguments instead of the old ``wsgirequest``
         type.
      
      Differential Revision: https://phab.mercurial-scm.org/D2832
      f0a85154
    • Gregory Szorc's avatar
      hgweb: support constructing URLs from an alternate base URL · 219b2335
      Gregory Szorc authored
      The web.baseurl config option allows server operators to define a
      custom URL for hosted content.
      
      The way it works today is that hgwebdir parses this config
      option into URL components then updates the appropriate
      WSGI environment variables so the request "lies" about its
      details. For example, SERVER_NAME is updated to reflect the
      alternate base URL's hostname.
      
      The WSGI environment should not be modified because WSGI
      applications may want to know the original request details (for
      debugging, etc).
      
      This commit teaches our request parser about the existence of
      an alternate base URL. If defined, the advertised URL and other
      self-reflected paths will take the alternate base URL into account.
      
      The hgweb WSGI application didn't use web.baseurl. But hgwebdir
      did. We update hgwebdir to alter the environment parsing
      accordingly. The old code around environment manipulation
      has been removed.
      
      With this change, parserequestfromenv() has grown to a bit
      unwieldy. Now that practically everyone is using it, it is
      obvious that there is some unused features that can be trimmed.
      So look for this in follow-up commits.
      
      Differential Revision: https://phab.mercurial-scm.org/D2822
      219b2335
    • Gregory Szorc's avatar
      hgweb: change how dispatch path is reported · d0b0fedb
      Gregory Szorc authored
      When I implemented the new request object, I carried forward some
      ugly hacks until I could figure out what was happening. One of those
      was the handling of PATH_INFO to determine how to route hgweb
      requests.
      
      Essentially, if we have PATH_INFO data, we route according to
      that. But if we don't, we route by the query string. I question
      if we still need to support query string routing. But that's for
      another day, I suppose.
      
      In this commit, we clean up the ugly "havepathinfo" hack and
      replace it with a "dispatchpath" attribute that can hold None or
      empty string to differentiate between the presence of PATH_INFO.
      This is still a bit hacky. But at least the request parsing
      and routing code is explicit about the meaning now.
      
      Differential Revision: https://phab.mercurial-scm.org/D2820
      d0b0fedb
    • Gregory Szorc's avatar
      hgweb: refactor repository name URL parsing · d7fd203e
      Gregory Szorc authored
      The hgwebdir WSGI application detects when a requested URL is for
      a known repository and it effectively forwards the request to the
      hgweb WSGI application.
      
      The hgweb WSGI application needs to route the request based on the
      base URL for the repository. The way this normally works is
      SCRIPT_NAME is used to resolve the base URL and PATH_INFO
      contains the path after the script.
      
      But with hgwebdir, SCRIPT_NAME refers to hgwebdir, not the base
      URL for the repository. So, there was a hacky REPO_NAME environment
      variable being set to convey the part of the URL that represented
      the repository so hgweb could ignore this path component for
      routing purposes.
      
      The use of the environment variable for passing internal state
      is pretty hacky. Plus, it wasn't clear from the perspective of
      the URL parsing code what was going on.
      
      This commit improves matters by making the repository name an
      explicit argument to the request parser. The logic around
      handling of this value has been shored up. We add various checks
      that the argument is used properly - that the repository name
      does represent the prefix of the PATH_INFO.
      
      Differential Revision: https://phab.mercurial-scm.org/D2819
      d7fd203e
    • Gregory Szorc's avatar
      tests: add test coverage for parsing WSGI requests · b2a3308d
      Gregory Szorc authored
      A subsequent commit will need to make this code more complicated
      in order to support alternate base URLs. Let's establish some test
      coverage before we diverge too far from PEP 3333.
      
      As part of this, a minor bug related to a missing SCRIPT_NAME
      key has been squashed.
      
      Differential Revision: https://phab.mercurial-scm.org/D2818
      b2a3308d
    • Gregory Szorc's avatar
      hgweb: stop passing req and tmpl into @webcommand functions (API) · 4daa2207
      Gregory Szorc authored
      We have effectively removed all consumers of the old wsgirequest
      type. The templater can be accessed on the requestcontext passed
      into the @webcommand function.
      
      For the most part, these arguments are unused. They only exist to
      provide backwards compatibility. And in the case of wsgirequest,
      use of that object could actively interfere with the new request
      object.
      
      So let's stop passing these objects to @webcommand functions.
      
      With this commit, wsgirequest is practically dead from the hgweb
      WSGI application. There are still some uses in hgwebdir though...
      
      .. api::
      
         @webcommand functions now only receive a single argument. The
         request and templater instances can be accessed via the
         ``req`` and ``templater`` attributes of the first argument.
         Note that the request object is different from previous Mercurial
         releases and consumers of the previous ``req`` 2nd argument
         will need updating to use the new API.
      
      Differential Revision: https://phab.mercurial-scm.org/D2803
      4daa2207
    • Gregory Szorc's avatar
      hgweb: transition permissions hooks to modern request type (API) · 02bea04b
      Gregory Szorc authored
      We're trying to remove ``wsgirequest``. The permissions hooks don't
      do anything they can't do with our new request type. So let's
      pass that in.
      
      This was the last use of ``wsgirequest`` in the wire protocol code!
      
      .. api::
      
         hgweb.hgweb_mod.permhooks no longer take a ``wsgirequest`` instance
         as an argument.
      
      Differential Revision: https://phab.mercurial-scm.org/D2793
      02bea04b
    • Gregory Szorc's avatar
      hgweb: port archive command to modern response API · 97f44b07
      Gregory Szorc authored
      Well, I tried to go with PEP 3333's recommendations and only allow
      our WSGI application to emit data via a response generator.
      Unfortunately, the "archive" command calls into the zipfile and
      tarfile modules and these operator on file objects and must send
      their data to an object with write(). There's no easy way turn
      these write() calls into a generator.
      
      So, we teach our response type how to expose a file object like
      object that can be used to write() output. We try to keep the API
      consistent with how things work currently: callers must call a
      setbody*(), then sendresponse() to trigger sending of headers,
      and only then can they get a handle on the object to perform
      writing.
      
      This required overloading the return value of @webcommand functions
      even more. Fortunately, we're almost completely ported off the
      legacy API. So we should be able to simplify matters in the near
      future.
      
      A test relying on this functionality has also been updated to use
      the new API.
      
      Differential Revision: https://phab.mercurial-scm.org/D2792
      97f44b07
    • Gregory Szorc's avatar
      tests: additional test coverage of archive web command · 40193f97
      Gregory Szorc authored
      This command is special in a few ways. First, it is the only command
      using the write() function from WSGI's start_response() function.
      Second, it is setting a custom content-disposition header.
      
      We change the test so it prints out full details of the HTTP
      response. We also save the response body to a file so we can
      verify its size and hash. The hash check will help ensure that
      archive generation is deterministic.
      
      Differential Revision: https://phab.mercurial-scm.org/D2790
      40193f97
  25. Mar 10, 2018
Loading