Skip to content
Snippets Groups Projects
  1. Aug 31, 2016
  2. Aug 26, 2016
    • Gregory Szorc's avatar
      bundle2: fail faster when interrupted · 9a9629b9416c
      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.
      9a9629b9416c
  3. Aug 07, 2016
  4. Aug 08, 2016
    • Mathias De Maré's avatar
      help: add example of '[templates]' usage · a12d13eac513
      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
      a12d13eac513
  5. Aug 05, 2016
    • Augie Fackler's avatar
      exchange: correctly specify url to unbundle (issue5145) · b8f9cdca8807
      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.
      b8f9cdca8807
  6. Aug 02, 2016
    • Durham Goode's avatar
      convert: move svn config initializer out of the module level · 09a5699cc3cb
      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.
      09a5699cc3cb
  7. Aug 04, 2016
  8. Aug 01, 2016
  9. Jul 31, 2016
  10. Jul 30, 2016
    • Katsunori FUJIWARA's avatar
      demandimport: avoid infinite recursion at actual module importing (issue5304) · 8960fcb76ca4
      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().
      8960fcb76ca4
  11. Jul 28, 2016
  12. Jul 29, 2016
  13. Jul 27, 2016
  14. Jul 28, 2016
  15. Jul 27, 2016
  16. Jul 25, 2016
  17. Jul 18, 2016
    • Matt Mackall's avatar
      extdiff: escape path for docstring (issue5301) · 67b180c0e263
      Matt Mackall authored
      The existing code (a) assumed path would be specified in
      encoding.encoding and (b) assumed unicode() objects wouldn't cause
      other parts of Mercurial to blow up. Both are dangerous assumptions.
      
      Since we don't know the encoding of path and can't pass non-ASCII
      through docstrings, just escape the path and drop the early _(). Will
      have to suffice until we can teach docstrings to handle UTF-8b
      escaping.
      
      This has the side-effect that the line containing the path is now
      variable by the time it reaches _() and thus can't be translated.
      67b180c0e263
  18. Jul 21, 2016
    • Kostia Balytskyi's avatar
      update: fix bug when update tries to modify folder symlink · b33c0c38d68f
      Kostia Balytskyi authored
      In 1e4512eac59e, I introduced a new bug:
      when a symlink points to a folder in commit A and to another folder
      in commit B, while updating from A to B, Mercurial will try to use
      removedir on this symlink, which will fail. This is a very bad bug,
      since it basically renders symlinks to folders unusable in repos.
      
      Added test case fails without a fix and passes with it.
      b33c0c38d68f
  19. Jul 25, 2016
  20. Jul 22, 2016
    • Yuya Nishihara's avatar
      templatekw: fix join format of parents keyword (issue5292) · 1a129dd05b7d
      Yuya Nishihara authored
      Since the default joinfmt() can't process a dict of multiple keywords, we
      need a dedicated joinfmt for showparents().
      
      Unlike revset(), parents are formatted as '{rev}:{node|formatnode}' by default.
      We copy the default formatting just like showextras() and showfilecopies() do.
      1a129dd05b7d
Loading