Skip to content
Snippets Groups Projects
  1. 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
  2. Feb 21, 2018
  3. Jan 18, 2018
    • Boris Feld's avatar
      revbranchcache: add the necessary bit to send 'rbc' data over bundle2 · c0e90df1
      Boris Feld authored
      Getbundle is now capable of sending rev-branch-cache information for the
      changesets it bundle. 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.
      
      The feature is still inactive since the capability is not advertised yet.
      c0e90df1
  4. 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
    • Boris Feld's avatar
      rev-branch-cache: add a function to generate a part · 79b73be4
      Boris Feld authored
      The function is able to produce a rbc part consumed by the function introduced
      into previous changesets. More details on usage and impact in the next
      changesets.
      79b73be4
    • Boris Feld's avatar
      revbranchcache: add a bundle2 handler for a rbc part · 9988fc10
      Boris Feld authored
      We add the necessary bit to process a part containing rev-branch-cache
      information. The local rev branch cache is then updated with the received
      information.
      
      Computing branch cache can become a significant part of the time spent pulling.
      9988fc10
  5. Jan 18, 2018
  6. Mar 15, 2018
    • Gregory Szorc's avatar
      httppeer: consolidate _requestbuilder assignments and document · 586891c5
      Gregory Szorc authored
      I collapsed multiple assignments because they don't appear to
      be necessary. We don't invoke the requestbuilder in anything
      called during __init__. So there's no reason to not define it
      earlier AFAICT.
      
      This seemingly useless attribute is actually an extension point.
      Document it as such.
      
      (A previous version of this patch removed the attribute because
      it appeared to just be an alias.)
      
      Differential Revision: https://phab.mercurial-scm.org/D2723
      586891c5
  7. Mar 05, 2018
  8. Mar 08, 2018
  9. Mar 14, 2018
    • Gregory Szorc's avatar
      util: prefer "bytesio" to "stringio" · 644a02f6
      Gregory Szorc authored
      The io.BytesIO and io.StringIO types enforce the type of
      data being operated on. On Python 2, we use cStringIO.StringIO(),
      which is lax about mixing types. On Python 3, we actually use
      io.BytesIO. Ideally, we'd use io.BytesIO on Python 2. But I believe
      its performance is poor compared to cString.StringIO().
      
      Anyway, we canonically define our pycompat type as "stringio."
      That name is misleading, especially on Python 3.
      
      This commit renames the canonical symbols to "bytesio."
      "stringio" is preserved as an alias for API compatibility. There
      are a lot of callers in the repo and I hesitate to take away the
      old name. I also don't feel like changing everything at this time.
      But at least new callers can use a "proper" name.
      
      Differential Revision: https://phab.mercurial-scm.org/D2868
      644a02f6
    • Augie Fackler's avatar
      contrib: fix a subtle bug in check-code's regex rewriting · a8d540d2
      Augie Fackler authored
      We rewrite `\s` to `[ \t]` when preparing our regular expressions, but
      we previously weren't working to avoid having nested sets. Previously,
      Python let this slide without incident, but in Python 3.7 wants to
      make sure you meant an actual [ in a set, and so this warns. This
      appears to be fortunate for us, because `[\s(]` was getting rewritten
      to be `[[ \t](]` which doesn't actually match what we expected. See
      preceding changes that were revealed to be necessary after
      implementing this fix.
      
      Differential Revision: https://phab.mercurial-scm.org/D2866
      a8d540d2
  10. Mar 13, 2018
  11. Feb 26, 2018
  12. Mar 13, 2018
  13. Feb 21, 2018
  14. Mar 14, 2018
  15. Mar 09, 2018
  16. Mar 05, 2018
  17. Mar 14, 2018
  18. Mar 13, 2018
  19. Mar 10, 2018
  20. Mar 09, 2018
  21. Mar 13, 2018
    • Jun Wu's avatar
      xdiff: move stdint.h to xdiff.h · a2baa61b
      Jun Wu authored
      It's more correct to put it in xdiff.h since that file actually uses int64_t
      etc and xdiff.h is included by xinclude.h.
      
      This should fix the oss-fuzz build. Thanks durin42 for discovering the
      issue.
      
      Test Plan:
      `make local` and xdiff related tests still work.
      
      Differential Revision: https://phab.mercurial-scm.org/D2848
      a2baa61b
  22. Mar 12, 2018
  23. Mar 13, 2018
  24. Mar 04, 2018
  25. Mar 02, 2018
  26. Mar 12, 2018
    • Martin von Zweigbergk's avatar
      rebase: extract function for rebasing a single node · 28f98809
      Martin von Zweigbergk authored
      We currently have _performrebase() and _performrebasesubset(), but we
      don't have a method for rebasing a single node (that's inside a loop
      in _performrebasesubset()). I think it makes sense to have such a
      method, so that's what this patch does. I think it may simplify future
      patches I'm working on that have to do with transactions, but I think
      this patch makes sense on its own whether or not that future work
      happens.
      
      Differential Revision: https://phab.mercurial-scm.org/D2809
      28f98809
  27. Mar 09, 2018
Loading