Skip to content
Snippets Groups Projects
  1. Oct 16, 2016
  2. Oct 01, 2016
  3. Sep 23, 2016
  4. Sep 02, 2016
    • timeless's avatar
      crecord: properly handle files with No newline at eof (issue5268) · e7766022
      timeless authored
      Yes, this bug was a single character with the wrong case...
      e7766022
    • Jun Wu's avatar
      annotate: pre-calculate the "needed" dictionary (issue5360) · 2f6d5c60
      Jun Wu authored
      The "needed" dict is used as a reference counter to free items in the giant
      "hist" dict. However, currently it is not very accurate and can lead to
      dropping "hist" items unnecessarily, for example, with the following DAG,
      
             -3-
            /   \
        0--1--2--4--
      
      The current algorithm will visit and calculate rev 1 twice, undesired. And
      it tries to be smart by clearing rev 1's parents: "pcache[1] = []" at the
      time hist[1] being accessed (note: hist[1] needs to be used twice, by rev 2
      and rev 3). It can result in incorrect results if p1 of rev 4 deletes chunks
      belonging to rev 0.
      
      However, simply removing "needed" is not okay, because it will consume 10x
      memory:
      
        # without any change
        % HGRCPATH= lrun ./hg annotate mercurial/commands.py -r d130a38 3>&2 [1]
        MEMORY   49074176
        CPUTIME  9.213
        REALTIME 9.270
      
        # with "needed" removed
        MEMORY   637673472
        CPUTIME  8.164
        REALTIME 8.249
      
      This patch moves "needed" (and "pcache") calculation to a separate DFS to
      address the issue. It improves perf and fixes issue5360 by correctly reusing
      hist, while maintaining low memory usage. Some additional attempt has been
      made to further reduce memory usage, like changing "pcache[f] = []" to "del
      pcache[f]". Therefore the result can be both faster and lower memory usage:
      
        # with this patch applied
        MEMORY   47575040
        CPUTIME  7.870
        REALTIME 7.926
      
      [1]: lrun is a lightweight sandbox built on Linux cgroup and namespace. It's
           used to measure CPU and memory usage here. Source code is available at
           github.com/quark-zju/lrun.
      2f6d5c60
  5. Sep 01, 2016
  6. Aug 31, 2016
  7. Aug 26, 2016
    • Gregory Szorc's avatar
      bundle2: fail faster when interrupted · 9a9629b9
      Gregory Szorc authored
      Before this patch, bundle2 application attempted to consume remaining
      bundle2 part data when the process is interrupted (SIGINT) or when
      sys.exit is called (translated into a SystemExit exception). This
      meant that if one of these occurred when applying a say 1 GB
      changegroup bundle2 part being downloaded over a network, it may take
      Mercurial *several minutes* to terminate after a SIGINT because the
      process is waiting on the network to stream megabytes of data. This is
      not a great user experience and a regression from bundle1. Furthermore,
      many process supervisors tend to only give processes a finite amount of
      time to exit after delivering SIGINT: if processes take too long to
      self-terminate, a SIGKILL is issued and Mercurial has no opportunity to
      clean up. This would mean orphaned locks and transactions. Not good.
      
      This patch changes the bundle2 application behavior to fail faster
      when an interrupt or system exit is requested. It does so by not
      catching BaseException (which includes KeyboardInterrupt and
      SystemExit) and by explicitly checking for these conditions in
      yet another handler which would also seek to the end of the current
      bundle2 part on failure.
      
      The end result of this patch is that SIGINT is now reacted to
      significantly faster: the active transaction is rolled back
      immediately without waiting for incoming bundle2 data to be consumed.
      This restores the pre-bundle2 behavior and makes Mercurial treat
      signals with the urgency they deserve.
      9a9629b9
  8. Aug 07, 2016
  9. Aug 08, 2016
    • Mathias De Maré's avatar
      help: add example of '[templates]' usage · a12d13ea
      Mathias De Maré authored
      V2:
      - move from shortest() with minlength 8 to minlength 4
      - mention [templates] in config.txt
      - better describe the difference between [templatealias] and [templates]
      
      V3:
      - choose a better example template
      a12d13ea
  10. Aug 05, 2016
    • Augie Fackler's avatar
      exchange: correctly specify url to unbundle (issue5145) · b8f9cdca
      Augie Fackler authored
      This parameter is slightly confusingly named in wireproto, so it got
      mis-specified from the start as 'push' instead of the URL to which we
      are pushing. Sigh. I've got a patch for that which I'll mail
      separately since it's not really appropriate for stable.
      
      Fixes a regression in bundle2 from bundle1.
      b8f9cdca
  11. Aug 02, 2016
    • Durham Goode's avatar
      convert: move svn config initializer out of the module level · 09a5699c
      Durham Goode authored
      The svn_config_get_config config call was being called at the module level, but
      had the potential to throw permission denied errors if ~/.subversion/servers was
      not readable. This could happen in certain test environments where the user
      permissions were very particular.
      
      This prevented the remotenames extension from loading, since it imports
      convert's hg module, which imports convert's subversion module, which calls
      this. The config is only ever used from this one constructor, so let's just move
      it in to there.
      09a5699c
  12. Aug 04, 2016
  13. Aug 01, 2016
  14. Jul 31, 2016
  15. Jul 30, 2016
    • Katsunori FUJIWARA's avatar
      demandimport: avoid infinite recursion at actual module importing (issue5304) · 8960fcb7
      Katsunori FUJIWARA authored
      Before this patch, importing C module on Windows environment causes
      infinite recursion call, if py2exe is used with -b2 option.
      
      At importing C module "a.b", extra hooking by zipextimporter of py2exe
      causes:
      
        0. assumption before accessing "b" of "a":
      
           - built-in module object is created for "a",
             (= "a" is actually imported)
           - _demandmod is created for "a.b" as a proxy object, and
             (= "a.b" is not yet imported)
           - an attribute "b" of "a" is initialized by the latter
      
        1. invocation of __import__ via _hgextimport() in _demandmod._load()
           for "a.b" implies _demandimport() for "a.b"
      
           This is unintentional, because _demandmod might be returned by
           _hgextimport() instead of built-in module object.
      
        2. _demandimport() at (1) is invoked with not context of "a", but
           context of zipextimporter
      
           Just after invocation of _hgextimport() in _demandimport(), an
           attribute "b" of the built-in module object for "a" is still
           bound to the proxy object for "a.b", because context of "a" isn't
           updated by actual importing "a.b". even though the built-in
           module object for "a.b" already appears in sys.modules.
      
           Therefore, chainmodules() returns _demandmod for "a.b", which is
           gotten from the attribute "b" of "a".
      
        3. processfromitem() on "a.b" causes _demandmod._load() for "a.b"
           again
      
           _demandimport() takes context of "a" in this case.
      
           Therefore, attributes below are bound to built-in module object
           for "a.b", as expected:
      
           - "b" of built-in module object for "a"
           - _module of _demandmod for "a.b"
      
        4. but _demandimport() invoked at (1) returns _demandmod object
      
           because _demandimport() just returns the object returned by
           chainmodules() at (3) above.
      
        5. then, _demandmod._load() causes infinite recursion call
      
           _demandimport() returns _demandmod for "a.b", and it is "self" at
           _demandmod._load().
      
      To avoid infinite recursion at actual module importing, this patch
      uses self._module, if _hgextimport() returns _demandmod itself. If
      _demandmod._module isn't yet bound at this point, execution should be
      aborted, because actual importing failed.
      
      In this patch, _demandmod._module is examined not on _demandimport()
      side, but on _demandmod._load() side, because:
      
        - the former has some exit points
        - only the latter uses _hgextimport(), except for _demandimport()
      
      BTW, this issue occurs only in the code path for non .py/.pyc files in
      zipextimporter (strictly speaking, in _memimporter) of py2exe.
      
      Even if zipextimporter is enabled, .py/.pyc files are handled by
      zipimporter, and it doesn't imply unintentional _demandimport() at
      invocation of __import__ via _hgextimport().
      8960fcb7
  16. Jul 28, 2016
  17. Jul 29, 2016
  18. Jul 27, 2016
  19. Jul 28, 2016
  20. Jul 27, 2016
Loading