Skip to content
Snippets Groups Projects
  1. Mar 03, 2017
  2. Mar 02, 2017
  3. Mar 01, 2017
  4. Feb 25, 2017
  5. Feb 23, 2017
  6. Feb 25, 2017
  7. Feb 24, 2017
    • Katsunori FUJIWARA's avatar
      worker: ignore meaningless exit status indication returned by os.waitpid() · 18fb3cf572b4
      Katsunori FUJIWARA authored
      Before this patch, worker implementation assumes that os.waitpid()
      with os.WNOHANG returns '(0, 0)' for still running child process. This
      is explicitly specified as below in Python API document.
      
          os.WNOHANG
              The option for waitpid() to return immediately if no child
              process status is available immediately. The function returns
              (0, 0) in this case.
      
      On the other hand, POSIX specification doesn't define the "stat_loc"
      value returned by waitpid() with WNOHANG for such child process.
      
          http://pubs.opengroup.org/onlinepubs/9699919799/functions/waitpid.html
      
      CPython implementation for os.waitpid() on POSIX doesn't take any care
      of this gap, and this may cause unexpected "exit status indication"
      even on POSIX conformance platform.
      
      For example, os.waitpid() with os.WNOHANG returns non-zero "exit
      status indication" on FreeBSD. This implies os.kill() with own pid or
      sys.exit() with non-zero exit code, even if no child process fails.
      
      To ignore meaningless exit status indication returned by os.waitpid(),
      this patch skips subsequent steps forcibly, if os.waitpid() returns 0
      as pid.
      
      This patch also arranges examination of 'p' value for readability.
      
      FYI, there are some issues below about this behavior reported for
      CPython.
      
          https://bugs.python.org/issue21791
          https://bugs.python.org/issue27808
      18fb3cf572b4
  8. Feb 13, 2017
  9. Feb 10, 2017
    • Pierre-Yves David's avatar
      wireproto: properly report server Abort during 'getbundle' · f3807a135e43
      Pierre-Yves David authored
      Previously Abort raised during 'getbundle' call poorly reported (HTTP-500 for
      http, some scary messages for ssh). Abort error have been properly reported for
      "push" for a long time, there is not reason to be different for 'getbundle'. We
      properly catch such error and report them back the best way available. For
      bundle, we issue a valid bundle2 reply (as expected by the client) with an
      'error:abort' part. With bundle1 we do as best as we can depending of http or
      ssh.
      f3807a135e43
    • Pierre-Yves David's avatar
      getbundle: cleanly handle remote abort during getbundle · d70971a3ae80
      Pierre-Yves David authored
      bundle2 allow the server to report error explicitly. This was initially
      implemented for push but there is not reason to not use it for pull too. This
      changeset add logic similar to the one in 'unbundle' to the
      client side of 'getbundle'. That logic make sure the error is properly reported
      as "remote". This will allow the server side of getbundle to send clean "Abort"
      message in the next changeset.
      d70971a3ae80
    • Pierre-Yves David's avatar
      bundle1: fix bundle1-denied reporting for pull over ssh · 3d4afc2fdcd7
      Pierre-Yves David authored
      Changeset b288fb2724bf introduced a config option to have the server deny pull
      using bundle1. The original protocol has not really been design to allow that
      kind of error reporting so some hack was used. It turned the hack only works on
      HTTP and that ssh server hangs forever when this is used. After further
      digging, there is no way to report the error in a unified way. Using `ooberror`
      freeze ssh and raising 'Abort' makes HTTP return a HTTP-500 without further
      details. So with sadness we implement a version that dispatch according to the
      protocol used.
      
      Now the error is properly reported, but we still have ungraceful abort after
      that. The protocol do not allow anything better to happen using bundle1.
      3d4afc2fdcd7
    • Pierre-Yves David's avatar
      bundle-tests: operate from outside a repository · f3c5a8a4dfd0
      Pierre-Yves David authored
      We are about to add a test for ssh pull/cloning being denied because of bundle1
      usage. For this, it is cleaner to not operate from the clone using http. So we
      update the test beforehand for clarity. This is more churns that what I'm happy
      to see on stable, but the rests of the series is worth it in my opinion.
      f3c5a8a4dfd0
    • Pierre-Yves David's avatar
      bundle1: display server abort hint during unbundle · accaa04f951c
      Pierre-Yves David authored
      The code was printing the abort message but not the hint. This is now fixed.
      accaa04f951c
    • Pierre-Yves David's avatar
      bundle1: fix bundle1-denied reporting for push over ssh · d554e624c5fe
      Pierre-Yves David authored
      Changeset b288fb2724bf introduced a config option to have the server deny push
      using bundle1. The original protocol has not really be design to allow such kind
      of error reporting so some hack was used. It turned the hack only works on HTTP
      and that ssh wire peer hangs forever when the same hack is used. After further
      digging, there is no way to report the error in a unified way. Using 'ooberror'
      freeze ssh and raising 'Abort' makes HTTP return a HTTP500 without further
      details. So with sadness we implement a version that dispatch according to the
      protocol used.
      
      We also add a test for pushing over ssh to make sure we won't regress in the
      future. That test show that the hint is missing, this is another bug fixed in
      the next changeset.
      d554e624c5fe
    • Pierre-Yves David's avatar
      bundle2: keep hint close to the primary message when remote abort · 4c8dcb491974
      Pierre-Yves David authored
      The remote hint message was ignored when reporting the remote error and
      passed to the local generic abort error. I think I might initially have
      tried to avoid reimplementing logic controlling the hint display depending of
      the verbosity level. However, first, there does not seems to have such verbosity
      related logic and second the resulting was wrong as the primary error and the
      hint were split apart. We now properly print the hint as remote output.
      4c8dcb491974
  10. Feb 11, 2017
    • Katsunori FUJIWARA's avatar
      misc: update year in copyright lines · 75149f84eac7
      Katsunori FUJIWARA authored
      This patch also makes some expected output lines in tests glob-ed for
      persistence of them.
      
      BTW, files below aren't yet changed in 2017, but this patch also
      updates copyright of them, because:
      
          - mercurial/help/hg.1.txt
      
            almost all of "man hg" output comes from online help of hg
            command, and is already changed in 2017
      
          - mercurial/help/hgignore.5.txt
          - mercurial/help/hgrc.5
      
            "copyright 2005-201X Matt Mackall" in them mentions about
            copyright of Mercurial itself
      75149f84eac7
  11. Feb 10, 2017
    • Katsunori FUJIWARA's avatar
      misc: replace domain of mercurial-devel ML address by mercurial-scm.org · 22a4f664c1a5
      Katsunori FUJIWARA authored
      This patch also adds new check-code.py pattern to detect invalid usage
      of "mercurial-devel@selenic.com".
      22a4f664c1a5
    • Katsunori FUJIWARA's avatar
      i18n: update Report-Msgid-Bugs-To property of *.po files · 4acf569facef
      Katsunori FUJIWARA authored
      This patch replaces domain of mercurial-devel ML address by
      mercurial-scm.org for "Report-Msgid-Bugs-To" property of each *.po
      files.
      
      This avoids releasing 4.1.1 with invalid "Report-Msgid-Bugs-To"
      in *.mo file, if corresponded *.po file isn't msgmerge-ed with recent
      hg.pot by translator.
      
      These *.po files aren't covered by check-code.py pattern newly added
      in subsequent patch, because it ignores them.
      4acf569facef
    • Katsunori FUJIWARA's avatar
      misc: replace domain of mercurial ML address by mercurial-scm.org · 561a019c0268
      Katsunori FUJIWARA authored
      This patch also adds new check-code.py pattern to detect invalid usage
      of "mercurial@selenic.com".
      
      Change for test-convert-tla.t is tested, but similar change for almost
      same test-convert-baz.t isn't yet tested actually, because I couldn't
      find out the way to get "GNU Arch baz client".
      
      AFAIK, buildbot skips test-convert-baz.t, too. Does anybody have
      appropriate environment for testing?
      561a019c0268
  12. Feb 04, 2017
  13. Feb 01, 2017
  14. Jan 30, 2017
    • Augie Fackler's avatar
      tests: correct (I think) command in test-largefiles-update · 2d6b86cadc10
      Augie Fackler authored
      When this test was introduced, it used the short-form of all the flags
      on this update invocation. I suspect, based on the "start with clean
      dirstates" comment and the fact that the no-exec branch of the #if
      guard leaves dirstate clean, that this should have been 'update -qCr'
      instead of 'update -qcr', but that a bug in largefiles --check
      handling left this problem unnoticed.
      
      I'll leave a breadcrumb further up about the current failure mode in
      the hopes that we can fix this some day.
      
      This was previously discussed in [0] but the trail in that thread goes
      cold after a few replies. Given that this is still a flaky test, that
      appears to only be passing by bad fortune, I think it's worth
      correcting the code of the test to make a correct assertion, and to
      keep track of the suspected bug with some other mechanism than an
      invalid test (if we had support for "expected failure" blocks this
      might be a worthwhile use of them?).
      
      0: https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-October/089501.html
      2d6b86cadc10
    • Augie Fackler's avatar
      tests: expand flags to long form in test-largefiles-update.t · 6cd99ec908fa
      Augie Fackler authored
      I spent some time confused by this test. I'm pretty sure that this
      line intends to be cleaning the dirstate, not checking that it's clean
      before updating: the preceding #if block leaves the dirstate clean in
      the noexec case, and dirty in the exec case, so we can't expect
      consistent behavior across that platform variation. A subsequent patch
      will modify this command to use --clean instead of --check.
      
      I'll elaborate in that patch about the hypothetical bug here.
      6cd99ec908fa
  15. Jan 31, 2017
    • kiilerix's avatar
      merge: fix crash on criss cross merge with dir move and delete (issue5020) · 41f6af50c0d8
      kiilerix authored
      Work around that 'dm' in the data model only can have one operation for the
      target file, but still can have multiple and conflicting operations on the
      source file where the other operation is a 'rm'. The move would thus fail with
      'abort: No such file or directory'.
      
      In this case it is "obvious" that the file should be removed, either before or
      after moving it. We thus keep the 'rm' of the source file but drop the 'dm'.
      
      This is not a pretty fix but quite "obviously" safe (famous last words...) as
      it only touches a rare code path that used to crash. It is possible that it
      would be better to swap the files for 'dm' as suggested on
      https://bz.mercurial-scm.org/show_bug.cgi?id=5020#c13 but it is not entirely
      obvious that it not just would create conflicts on the other file. That can be
      revisited later.
      41f6af50c0d8
    • kiilerix's avatar
      tests: use 'f' in test-merge-criss-cross.t to prepare for recursive dumping · 72c36a2be2d6
      kiilerix authored
      Prepare for adding a test case with files in a directory.
      72c36a2be2d6
    • Martin von Zweigbergk's avatar
      util: make sortdict.keys() return a copy · 0126e422450e
      Martin von Zweigbergk authored
      dict.keys() is documented to return a copy, so it's surprising that
      sortdict.keys() did not. I noticed this because we have an extension
      that calls readlocaltags(). That method tries to remove any tags that
      point to non-existent revisions (most likely stripped). However, since
      it's unintentionally working on the instance it's modifying, it
      sometimes fails to remove tags when there are multiple bad tags in a
      row. This was not caught because localrepo.tags() does an additional
      layer of filtering.
      
      sortdict is also used in other places, but I have not checked whether
      its keys() and/or __delitem__() methods are used there.
      0126e422450e
  16. Jan 30, 2017
  17. Jan 29, 2017
    • Danek Duvall's avatar
      tests: account for different newline behavior between Solaris and GNU grep · cdeb0804d98c
      Danek Duvall authored
      GNU grep, when emitting a matching line that doesn't have a terminating
      newline, will add an extra newline.  Solaris grep passes the original line
      through without the newline.  This causes differences in test output when
      looking at the last line of the output of get-with-headers.py, which
      doesn't usually emit (and certainly doesn't guarantee) a terminating
      newline.
      
      Both grep implementations succeed in matching the requested pattern,
      though, so rely on specifying the full pattern on grep's commandline
      instead of expecting it in the output, and send the output to /dev/null.
      cdeb0804d98c
  18. Jan 20, 2017
    • Augie Fackler's avatar
      tests: also allow "Protocol not supported" in test-http-proxy error · 7bfe02b57695
      Augie Fackler authored
      I've seen this in a (misconfigured) FreeBSD jail which has ::1 as an
      entry for localhost, but IPv6 support is disabled in the jail. It took
      me months to figure out what was going on (and I only figured it out
      when tinyproxy.py got confused by similar IPv4-level misconfiguration
      of the localhost domain in /etc/hosts.)
      
      I don't feel strongly about this patch: on the one hand, it's papering
      over a host-level misconfiguration, but on the other it avoids some
      weird and hard to diagnose problems that can occur in weirdly
      restricted environments.
      7bfe02b57695
    • Yuya Nishihara's avatar
      revset: prevent using outgoing() and remote() in hgweb session (BC) · 41e31a6f5296
      Yuya Nishihara authored
      outgoing() and remote() may stall for long due to network I/O, which seems
      unsafe per definition, "whether a predicate is safe for DoS attack." But I'm
      not 100% sure about this. If our concern isn't elapsed time but CPU resource,
      these predicates are considered safe. Perhaps that would be up to the
      web/application server configuration?
      
      Anyway, outgoing() and remote() wouldn't be useful in hgweb, so I think
      it's okay to ban them.
      41e31a6f5296
  19. Jan 19, 2017
Loading