Skip to content
Snippets Groups Projects
  1. May 02, 2017
  2. Apr 30, 2017
  3. May 02, 2017
  4. May 01, 2017
    • Pierre-Yves David's avatar
      pager: rename 'pager.enable' to 'ui.paginate' · f06d23af
      Pierre-Yves David authored
      This aligns with what we do for color (see 7fec37746417). Pager is a central
      enough notion that having the master config in the [ui] section makes senses. It
      will helps with consistency, discoverability. It will also help having a simple
      and clear example hgrc mentioning pager.
      
      The previous form of the option had never been released in a non-rc version but
      we keep it around for convenience. If both are set, 'ui.pager' take priority.
      f06d23af
  5. May 02, 2017
    • Pierre-Yves David's avatar
      color: special case 'always' in 'ui.color' · 9a98023a
      Pierre-Yves David authored
      This lift the confusing case, where 'ui.color=always' would actually not always
      use color.
      9a98023a
    • Pierre-Yves David's avatar
      color: turn 'ui.color' into a boolean (auto or off) · 9a85ea1d
      Pierre-Yves David authored
      Previously, 'ui.color=yes' meant "always show color", While
      "ui.color=auto" meant "use color automatically when it appears
      sensible".
      
      This feels problematic to some people because if an administrator has
      disabled color with "ui.color=off", and a user turn it back  on using
      "color=on", it will get surprised (because it breaks their output when
      redirected to a file.) This patch changes ui.color=true to only move the
      default value of --color from "never" to "auto".
      
      I'm not really in favor of this changes as I suspect the above case will
      be pretty rare and I would rather keep the logic simpler. However, I'm
      providing this patch to help the 4.2 release in the case were others
      decide to make this changes.
      
      Users that want to force colors without specifying --color on the
      command line can use the 'ui.formatted' config knob, which had to be
      enabled in a handful of tests for this patch.
      
      Nice summary table (credit: Augie Fackler)
      
      That is, before this patch:
      
      +--------------------+--------------------+--------------------+
      |                    | not a tty          | a tty              |
      |                    | --color not set    | --color not set    |
      |                    |                    |                    |
      +--------------------+--------------------+--------------------+
      | [ui]               |                    |                    |
      | color (not set)    | no color           | no color           |
      |                    |                    |                    |
      +--------------------+--------------------+--------------------+
      | [ui]               |                    |                    |
      | color = auto       | no color           | color              |
      |                    |                    |                    |
      +--------------------+--------------------+--------------------+
      | [ui]               |                    |                    |
      | color = yes        | *color*            | color              |
      |                    |                    |                    |
      +--------------------+--------------------+--------------------+
      | [ui]               |                    |                    |
      | color = no         | no color           | no color           |
      |                    |                    |                    |
      +--------------------+--------------------+--------------------+
      (if --color is specified, it always clobbers the setting in [ui])
      
      and after this patch:
      
      +--------------------+--------------------+--------------------+
      |                    | not a tty          | a tty              |
      |                    | --color not set    | --color not set    |
      |                    |                    |                    |
      +--------------------+--------------------+--------------------+
      | [ui]               |                    |                    |
      | color (not set)    | no color           | no color           |
      |                    |                    |                    |
      +--------------------+--------------------+--------------------+
      | [ui]               |                    |                    |
      | color = auto       | no color           | color              |
      |                    |                    |                    |
      +--------------------+--------------------+--------------------+
      | [ui]               |                    |                    |
      | color = yes        | *no color*         | color              |
      |                    |                    |                    |
      +--------------------+--------------------+--------------------+
      | [ui]               |                    |                    |
      | color = no         | no color           | no color           |
      |                    |                    |                    |
      +--------------------+--------------------+--------------------+
      (if --color is specified, it always clobbers the setting in [ui])
      9a85ea1d
  6. May 01, 2017
  7. Apr 19, 2017
  8. May 01, 2017
    • Pierre-Yves David's avatar
      color: point to the global help in the example hgrc · 2de67783
      Pierre-Yves David authored
      This is probably the best way to have users learn more is they need too.
      2de67783
    • Pierre-Yves David's avatar
      color: reflect the new default in the example hgrc · 4d438efb
      Pierre-Yves David authored
      Color is enabled by default so un-commenting the line would not have any effect.
      We'll point to the help in the next changeset.
      4d438efb
    • Pierre-Yves David's avatar
      color: point to the config help in global help topic · 1e0f3723
      Pierre-Yves David authored
      We point out at the help of the config option for user who wants to learn more
      about the possible config value.
      
      The suggested command returns some other extra (color related) results, but this
      is bug to fix outside of the freeze.
      1e0f3723
    • Pierre-Yves David's avatar
      color: reflect the new default in global help topic · a8f15bf8
      Pierre-Yves David authored
      We point out that color is enabled by default.
      a8f15bf8
    • Martin von Zweigbergk's avatar
      docs: describe ui.color consistently with --color · c401be73
      Martin von Zweigbergk authored
      The --color option is described to accept "boolean, always, auto,
      never, or debug". Let's use a similar description for ui.color. Also
      fix the formatting to use double quotes as we seem to use for about
      half the values in config.txt (the other half uses double
      backticks). Also use uppercase Boolean for consistency within the
      file.
      c401be73
    • Pierre-Yves David's avatar
      test: glob out variation from 'HGPORT' length · f942dc80
      Pierre-Yves David authored
      On system where HGTEST_PORT is configured to a value an order a magnitude lower
      or higher than the default. The number of digit in the HGPORT changes and this
      test breaks.
      f942dc80
    • Katsunori FUJIWARA's avatar
      lock: avoid unintentional lock acquisition at failure of readlock · 0d892d82
      Katsunori FUJIWARA authored
      Acquiring lock by vfs.makelock() and getting lock holder (aka
      "locker") information by vfs.readlock() aren't atomic action.
      Therefore, failure of the former doesn't ensure success of the latter.
      
      Before this patch, lock is unintentionally acquired, if ENOENT
      causes failure of vfs.readlock() while 5 times retrying, because
      lock._trylock() returns to caller silently after retrying, and
      lock.lock() assumes that lock._trylock() returns successfully only if
      lock is acquired.
      
      In this case, lock symlink (or file) isn't created, even though lock
      is treated as acquired in memory.
      
      To avoid this issue, this patch makes lock._trylock() raise
      LockHeld(EAGAIN) at the end of it, if lock isn't acquired while
      retrying.
      
      An empty "locker" meaning "busy for frequent lock/unlock by many
      processes" might appear in an abortion message, if lock acquisition
      fails. Therefore, this patch also does:
      
        - use '%r' to increase visibility of "locker", even if it is empty
        - show hint message to explain what empty "locker" means
      0d892d82
    • Katsunori FUJIWARA's avatar
      lock: avoid unintentional lock acquisition at failure of readlock · e1938d60
      Katsunori FUJIWARA authored
      Acquiring lock by vfs.makelock() and getting lock holder (aka
      "locker") information by vfs.readlock() aren't atomic action.
      Therefore, failure of the former doesn't ensure success of the latter.
      
      Before this patch, lock is unintentionally acquired, if
      self.parentlock is None (this is default value), and lock._readlock()
      returns None for ENOENT at vfs.readlock(), because these None are
      recognized as equal to each other.
      
      In this case, lock symlink (or file) isn't created, even though lock
      is treated as acquired in memory.
      
      To avoid this issue, this patch retries lock acquisition immediately,
      if lock._readlock() returns None "locker".
      
      This issue will be covered by a test added in subsequent patch,
      because simple emulation of ENOENT at vfs.readlock() easily causes
      another issue.  "raising ENOENT only at the first vfs.readlock()
      invocation" is too complicated for unit test, IMHO.
      e1938d60
  9. Apr 30, 2017
  10. Apr 25, 2017
    • Boris Feld's avatar
      packaging: add make target for linux wheels · fcddcf44
      Boris Feld authored
      Having linux wheels is going to helps system without compiler or python-dev
      plus speed up the installation for everyone.
      
      I followed the manylinux example repository
      https://github.com/pypa/python-manylinux-demo
      to add a make target (build-linux-wheels) using
      official docker image to build python 2 linux wheels
      for mercurial. It generates Python 2.6 and Python 2.7 for both
      32 and 64 bits architectures.
      
      I had to blacklist several test cases for various reasons:
      * test-convert-git.t and test-subrepo-git.t because of the git version
      * test-patchbomb-tls.t because of warning using tls 1.0
        It's likely because the docker image is based on centos 5.0 and
        openssl is outdated.
      fcddcf44
    • Boris Feld's avatar
      tests: fix two http tests to also pass inside manylinux1 docker · 76ed6063
      Boris Feld authored
      This will let us build Linux wheels.
      76ed6063
  11. Apr 28, 2017
  12. Apr 26, 2017
  13. Apr 20, 2017
  14. Apr 18, 2017
  15. Apr 25, 2017
  16. Apr 24, 2017
    • Denis Laxalde's avatar
      hgweb: change text of followlines links to "older / newer" · 1cf0b651
      Denis Laxalde authored
      DAG directions "descending" / "ascending" arguably do not make much sense in
      the web interface where changes are usually listed by "dates".
      1cf0b651
    • Denis Laxalde's avatar
      hgweb: do not show "descending" link in followlines UI for filelog heads · a298f5c6
      Denis Laxalde authored
      When on a filelog head, we are certain that there will be no descendant so the
      target of the "descending" link will lead to an empty log result. Do not
      display the link in this case.
      a298f5c6
    • Denis Laxalde's avatar
      context: optimize linkrev adjustment in blockancestors() (issue5538) · a457da52
      Denis Laxalde authored
      We set parent._descendantrev = child.rev() when walking parents in
      blockancestors() so that, when linkrev adjustment is perform for these, it
      starts from a close descendant instead of possibly topmost introrev. (See
      `self._adjustlinkrev(self._descendantrev)` in filectx._changeid().)
      
      This is similar to changeset c82d88dfaf59, which added a "f._changeid"
      instruction in annotate() for the same purpose.
      However, here, we set _descendantrev explicitly instead of relying on the
      '_changeid' cached property being accessed (with effect to set _changeid
      attribute) so that, in _parentfilectx() (called from parents()), we go through
      `if '_changeid' in vars(self) [...]` branch in which instruction
      `fctx._descendantrev = self.rev()` finally appears and does what we want.
      
      With this, we can roughly get a 3x speedup (including in example of issue5538
      from mozilla-central repository) on usage of followlines revset (and
      equivalent hgweb request).
      a457da52
Loading