Skip to content
Snippets Groups Projects
  1. Sep 24, 2017
    • Yuya Nishihara's avatar
      scmutil: extract helper functions that returns human-readable change id · 4647e0a8
      Yuya Nishihara authored
      We do "'%d:%s' % (ctx...)" at several places, so let's formalize it. A low-
      level function, formatrevnode(ui, rev, node), is extracted so we can pass
      a manifest rev/node pair.
      
      Note that hex() for manifest output can be replaced with hexfunc() because
      it is printed only when debugflag is set.
      
      i18n/de.po is updated so test-log.t passes with no error.
      4647e0a8
  2. Sep 02, 2017
  3. Sep 09, 2017
  4. Sep 26, 2017
    • Boris Feld's avatar
      pull: remove inadequate use of operations records to update stepdone · 6c7aaf59
      Boris Feld authored
      The 'stepdone' set is design to be a client side mechanism. If the client used
      some advanced capabilities to request necessary information (changeset,
      obsmarkers, phases, etc). It marks the steps as done to avoid having a less
      advanced mechanism issue a duplicated request.
      
      So, the "stepdone.add('phases')" should be the result of a client choice,
      because only the client can know it has requested all it needed to request. In
      4a08cf1a2cfe this principle was broken because any phase-heads part sent by
      the server to the client would declare the phases retrieval complete.
      
      Now that there is an official phases related capability and code associated to
      it. We do not need the change in 4a08cf1a2cfe anymore and we can back it out.
      This brings back 'stepdone' management for 'phases' in line with the rest of
      the code (including other phases handing).
      
      Here is an example of potential misbehavior that 4a08cf1a2cfe introduced:
      
      Imagine a server that pre-computes bundles. The bundles contains a changegroup
      part and an (advisory) 'phase-heads' part. When a pull occurs, precomputed
      bundled are reused if available. As the phase part is advisory it can be sent
      to all clients.  However they could be relevant changesets without phase
      information.  Either because they are already common or because they had no
      precomputed bundle for them yet.
      
      If receiving any 'phase-heads' parts disable subsequent phases re-trivial
      parts, the client will not request phase data for all relevant changesets. For
      example common changesets will not turn public.
      6c7aaf59
  5. Sep 24, 2017
    • Boris Feld's avatar
      pull: use 'phase-heads' to retrieve phase information · 10e162bb
      Boris Feld authored
      A new bundle2 capability 'phases' has been added. If 'heads' is part of the
      supported value for 'phases', the server supports reading and sending 'phase-
      heads' bundle2 part.
      
      Server is now able to process a 'phases' boolean parameter to 'getbundle'. If
      'True', a 'phase-heads' bundle2 part will be included in the bundle with phase
      information relevant to the whole pulled set. If this method is available the
      phases listkey namespace will no longer be listed.
      
      Beside the more efficient encoding of the data, this new method will greatly
      improve the phase exchange efficiency for repositories with non-served
      changesets (obsolete, secret) since we'll no longer send data about the
      filtered heads.
      
      Add a new 'devel.legacy.exchange' config item to allow fallback to the old
      'listkey in bundle2' method.
      
      Reminder: the pulled set is not just the changesets bundled by the pull. It
      also contains changeset selected by the "pull specification" on the client
      side (eg: everything for bare pull). One of the reason why the 'pulled set' is
      important is to make sure we can move -common- nodes to public.
      10e162bb
  6. Sep 20, 2017
    • Boris Feld's avatar
      bundle2: only grab a transaction when 'phase-heads' affect the repository · 4ef472b9
      Boris Feld authored
      The next patch will use the 'phase-heads' part to exchange phase data relevant to
      the pulled set.
      
      'handlephases' currently acquires a transaction even in case of no-op pull,
      which would results in an empty transaction and messing with the existing
      journal.
      
      Pass the transaction fetcher to updatephases so it can fetch it if necessary.
      4ef472b9
  7. Sep 19, 2017
  8. Sep 20, 2017
    • Boris Feld's avatar
      discovery: avoid dropping remote heads hidden locally · e45ec589
      Boris Feld authored
      An extra post processing was added to recognize remote heads that are hidden
      locally as "common" instead of "unknown". However, this processing was
      removing such hidden heads from the remote heads sets.
      
      It had no impact because we used to pull phase information from all remote
      heads.
      
      This series will replace the phase pulling operation to a more efficient
      process but requires the unmodified pulled set information.
      e45ec589
  9. Sep 29, 2017
  10. Sep 28, 2017
    • Jun Wu's avatar
      test-patchbomb: fix the test · 98b35921
      Jun Wu authored
      With the experimental config `progress.estimate` removed, the progress
      output in `test-patchbomb.t` has a minor change: it shows ETA since the
      beginning.
      
      (This could be folded into f428c3)
      98b35921
  11. Sep 27, 2017
    • Jun Wu's avatar
      progress: make ETA only consider progress made in the last minute · a667f0ca
      Jun Wu authored
      This patch limits the estimate time interval to roughly the last minute
      (configurable by `estimateinterval`) to be more practical. See the test
      change for why this is better.
      
      .. feature:: Estimated time is more accurate with non-linear progress
      
      Differential Revision: https://phab.mercurial-scm.org/D820
      a667f0ca
    • Jun Wu's avatar
      progress: remove progress.estimate config · f428c347
      Jun Wu authored
      It was introduced by 98e4d3914c2e ("progress: add speed format" 2011-5-9) and was
      intended to hide ETA information for the first few seconds.
      
      Later 5d261fd00446 ("progress: add a changedelay to prevent parallel topics from
      flapping (issue2698)" 2011-6-23) introduced `changedelay` config which hides
      the entire progress bar for the first few seconds. So `progress.estimate` seems
      somehow duplicated feature-wise. Since it's experimental and duplicated, let's
      just remove it. This makes the next patch simpler - it no longer needs to make
      sure `starttimes` is the real start time.
      
      Differential Revision: https://phab.mercurial-scm.org/D828
      f428c347
  12. Sep 26, 2017
    • Jun Wu's avatar
      progress: demonstrate non-linear progress has a bad ETA experience · d64c2c05
      Jun Wu authored
      Previously, the ETA and speed assumes the progress is linear. Often, due to
      network or other issues, it could be fast for the most time, and suddenly
      slow down:
      
          [====================================================>         ]
           \___________________________________________/\______/
              very fast                                  suddenly much slower
      
      This patch adds a test demonstrating the ETA could be way off in those
      cases.
      
      Differential Revision: https://phab.mercurial-scm.org/D819
      d64c2c05
  13. Sep 21, 2017
    • Pulkit Goyal's avatar
      copytrace: add a a new config to limit the number of drafts in heuristics · 1826d695
      Pulkit Goyal authored
      The heuristics options tries to the default full copytracing algorithm if both
      the source and destination branches contains of non-public changesets only. But
      this can be slow in cases when we have a lot of drafts.
      
      This patch adds a new config option experimental.copytrace.sourcecommitlimit
      which defaults to 100. This value will be the limit of number of drafts from c1
      to base. Incase there are more changesets even though they are draft, the
      heuristics algorithm will be used.
      
      Differential Revision: https://phab.mercurial-scm.org/D763
      1826d695
  14. Sep 26, 2017
  15. Sep 23, 2017
  16. Sep 25, 2017
  17. Aug 19, 2017
  18. Sep 23, 2017
  19. Sep 24, 2017
  20. Sep 14, 2017
  21. Jun 14, 2017
  22. Sep 21, 2017
  23. Sep 12, 2017
  24. Sep 13, 2017
    • Mark Thomas's avatar
      revlog: add option to mmap revlog index · 3c969172
      Mark Thomas authored
      Following on from Jun Wu's patch last October[1], we have found that using mmap
      for the revlog index in repos with large revlogs gives a noticable performance
      improvment (~110ms on each hg invocation), particularly for commands that don't
      touch the index very much.
      
      This changeset adds this as an option, activated by a new experimental config
      option so that it can be enabled on a per-repo basis. The configuration option
      specifies an index size threshold at which Mercurial will switch to using mmap
      to access the index.
      
      If the configuration option is not specified, the default remains to load the
      full file, which seems to be the best option for smaller repos.
      
      Some initial performance numbers for average of 5 invocations of `hg log -l 5`
      for different cache states:
      
      | Repo: | HG | FB |
      |---|---|---|
      | Index size: | 2.3MB | much bigger |
      | read (warm): | 237ms | 432ms |
      | mmap (warm): | 227ms | 321ms |
      |   | (-3%) | (-26%) |
      | read (cold): | 397ms | 696ms |
      | mmap (cold): | 410ms | 888ms |
      |   | (+3%) | (+28%) |
      
      [1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-October/088737.html
      
      Test Plan:
      `hg log --config experimental.mmapindex=true`
      
      Differential Revision: https://phab.mercurial-scm.org/D477
      3c969172
  25. Sep 21, 2017
  26. Sep 20, 2017
  27. Sep 03, 2017
    • Pulkit Goyal's avatar
      copytrace: use the full copytracing method if only drafts are involved · fc3b8483
      Pulkit Goyal authored
      This patch adds the functionality to use the full copytracing even if
      `experimental.copytrace = heuristics` in cases when drafts are involved.
      
      This is also a part of copytrace extension in fbext.
      
      This also adds tests which are also taken from fbext.
      
      .. feature::
      
         The `heuristics` option for `experimental.copytrace` performs full
         copytracing if both source and destination branches contains non-public
         changsets only.
      
      Differential Revision: https://phab.mercurial-scm.org/D625
      fc3b8483
Loading