Skip to content
Snippets Groups Projects
  1. Feb 10, 2017
    • 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
  2. Feb 04, 2017
  3. Feb 01, 2017
  4. 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
  5. 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
  6. Jan 30, 2017
  7. 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
  8. 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
  9. Jan 19, 2017
  10. Jan 18, 2017
  11. Jan 17, 2017
  12. Jan 18, 2017
  13. Jan 17, 2017
    • Anton Shestakov's avatar
      tests: test experimental.spacemovesdown config for commit -i · 9f264adbe75b
      Anton Shestakov authored
      The feature is still very experimental, but at least its behavior is captured
      in the test.
      9f264adbe75b
    • Gregory Szorc's avatar
      zstd: prevent potential free() of uninitialized memory · 08fa3a76a080
      Gregory Szorc authored
      This is a cherry pick of an upstream fix. The free() of uninitialed
      memory could likely only occur if a malloc() inside zstd fails.
      
      The patched functions aren't currently used by Mercurial. But I don't
      like leaving footguns sitting around.
      08fa3a76a080
    • Martin von Zweigbergk's avatar
      revlog: give EXTSTORED flag value to narrowhg · 08b34c3a6f74
      Martin von Zweigbergk authored
      Narrowhg has been using "1 << 14" as its revlog flag value for a long
      time. We (Google) have many repos with that value in production
      already. When the same value was reserved for EXTSTORED, it made those
      repos invalid. Upgrading them will be a little painful. We should
      clearly have reserved the value for narrowhg a long time ago. Since
      the EXTSTORED flag is not yet in any release and Facebook also says
      they have not started using it in production, so it should be okay to
      change it. This patch gives the current value (1 << 14) back to
      narrowhg and gives a new value (1 << 13) to EXTSTORED.
      08b34c3a6f74
    • Martin von Zweigbergk's avatar
      help: don't let tools reflow revlog flags list · 0b792507ea15
      Martin von Zweigbergk authored
      Before this change, the text about revlog flags was reflowed into a
      single paragraph, which made it a bit hard to read. I don't even know
      the rules around this, but adding a blank line before each flag seems
      to prevent the reflowing.
      0b792507ea15
Loading