Skip to content
Snippets Groups Projects
  1. Aug 01, 2014
  2. Jul 31, 2014
  3. Jul 30, 2014
  4. Jul 26, 2014
  5. Jul 30, 2014
  6. Jul 29, 2014
    • Wagner Bruna's avatar
      i18n-pt_BR: synchronized with ad56fc55cbc3 · 5341c500
      Wagner Bruna authored
      5341c500
    • Katsunori FUJIWARA's avatar
      doc: unify help text for "--edit" option · 3838b910
      Katsunori FUJIWARA authored
      This patch changes help text for "--edit" option of commands below:
      
        - fetch
        - qnew
        - qrefresh
        - qfold
        - commit
        - tag
      
      This unification reduces translation cost, too.
      
      This patch chooses not "further edit commit message already specified"
      (of "hg commit") but "invoke editor on commit messages" as unified
      help text for "--edit" option, because the latter is much older than
      the former.
      3838b910
    • Katsunori FUJIWARA's avatar
      doc: unify help text for "--message" option · 59af0b21
      Katsunori FUJIWARA authored
      This patch changes help text for "--message" option of commands below
      for unification.
      
        - sign (of gpg)
        - tag
      
      This unification reduces translation cost, too.
      
      This patch doesn't change the description for "--message" of "hg
      rebase" below, because this should contain "collapse" word to explain
      its purpose (only for "--collapse") clearly.
      
          use text as collapse commit message
      59af0b21
  7. Jul 28, 2014
  8. Jul 26, 2014
  9. Jul 25, 2014
  10. Jul 21, 2014
  11. Jul 24, 2014
    • Yuya Nishihara's avatar
      test-status: add test for removed-and-untracked state (BC) · 64fe488b
      Yuya Nishihara authored
      In Mercurial 3.0, "hg status" can list the same file twice if it was removed
      but still exists in working directory, i.e. removed by "hg forget":
      
        $ hg status --rev 0 removed
        R removed
        ? removed
      
      But since 65cdc6bab91e, untracked state, "?", is no longer displayed in this
      example.
      
      I think the new behavior is correct since a file should have single state, but
      if it is a bug, this patch should be dropped.
      64fe488b
  12. Jul 02, 2014
    • Pierre-Yves David's avatar
      bundle2: only use callable return as reply handler · dab31290
      Pierre-Yves David authored
      When a bundle2 parts generator returns a non callable value, it should not be
      used as a reply handler. The changegroup part generator is already having this
      case of behavior when there is no changegroup to push. This changeset prevent a
      crash for user of the experimentable bundle2 feature.
      dab31290
  13. Jul 24, 2014
    • Nathan Goldbaum's avatar
      resolve: report no argument warning using a hint · 9209c02f
      Nathan Goldbaum authored
      With this change resolve and revert produce consistent output when run with no
      arguments:
      
      $ hg resolve
      abort: no files or directories specified
      (use --all to remerge all files)
      
      $ hg revert
      abort: no files or directories specified
      (use --all to revert all files)
      9209c02f
    • Gregory Szorc's avatar
      revset: optimize baseset.__sub__ (issue4313) · f486001f
      Gregory Szorc authored
      dd716807fd23 regressed performance of baseset.__sub__ by introducing
      a lazyset. This patch restores that lost performance by eagerly
      evaluating baseset.__sub__ if the other set is a baseset.
      
      revsetbenchmark.py results impacted by this change:
      
      revset #6: roots(0::tip)
      0) wall 2.923473 comb 2.920000 user 2.920000 sys 0.000000 (best of 4)
      1) wall 0.077614 comb 0.080000 user 0.080000 sys 0.000000 (best of 100)
      
      revset #23: roots((0:tip)::)
      0) wall 2.875178 comb 2.880000 user 2.880000 sys 0.000000 (best of 4)
      1) wall 0.154519 comb 0.150000 user 0.150000 sys 0.000000 (best of 61)
      
      On the author's machine, this slowdown manifested during evaluation of
      'roots(%ln::)' in phases.retractboundary after unbundling the Firefox
      repository. Using `time hg unbundle firefox.hg` as a benchmark:
      
      Before: 8:00
      After:  4:28
      Delta: -3:32
      
      For reference, the subset and cs baseset instances impacted by this
      change were of lengths 193634 and 193627, respectively.
      
      Explicit test coverage of roots(%ln::), while similar to the existing
      roots(0::tip) benchmark, has been added.
      f486001f
  14. Jul 16, 2014
  15. Jul 23, 2014
  16. Jul 20, 2014
  17. Jul 22, 2014
    • Katsunori FUJIWARA's avatar
      largefiles: use "normallookup" on "lfdirstate" while reverting · 0cb34b39
      Katsunori FUJIWARA authored
      Before this patch, largefiles gotten from revisions other than the
      parent of the working directory at "hg revert" become "clean"
      unexpectedly in steps below:
      
          1. "repo.status()" is invoked (for status check before reverting)
            1-1 "dirstate" entry for standinfile SF is "normal"-ed
           (1-2 "lfdirstate" entry of largefile LF (for SF) is "normal"-ed)
      
          2. "cmdutil.revert()" is invoked
            2-1 standinfile SF is updated in the working directory
            2-2 "dirstate" entry for SF is NOT updated
      
          3. "lfcommands.updatelfiles()" is invoked (by "overrides.overriderevert()")
            3-1 largefile LF (for SF) is updated in the working directory
            3-2 "dirstate" returns "n" and valid timestamp for SF (by 1-1 and 2-2)
            3-3 "lfdirstate" entry for LF is "normal"-ed
            3-4 "lfdirstate" is written into ".hg/largefiles/dirstate", and
                timestamp of LF is stored into "lfdirstate" file (by 3-3)
                (ASSUMPTION: timestamp of LF differs from one of "lfdirstate" file)
      
      Then, "hs status" treats LF as "clean", even though LF is updated by
      "other" revision (by 3-1), because "lfilesrepo.status()" always treats
      "normal"-ed files (by 3-3 and 3-4) as "clean".
      
      When largefiles are reverted, they should be "normallookup"-ed
      forcibly.
      
      This patch uses "normallookup" on "lfdirstate" while reverting, by
      passing "True" to newly added argument "normallookup".
      
      Forcible "normallookup"-ing is not so expensive, because list of
      target largefiles is explicitly specified in this case.
      
      This patch uses "[debug] dirstate.delaywrite" feature in the test, to
      ensure that timestamp of the largefile gotten from "other" revision is
      stored into ".hg/largefiles/dirstate" (for ASSUMPTION at 3-4)
      0cb34b39
    • Katsunori FUJIWARA's avatar
      largefiles: invoke "normallookup" on "lfdirstate" for merged files · 8ecbe55f
      Katsunori FUJIWARA authored
      Before this patch, largefiles gotten from "other" revision (with
      conflict) at "hg merge" become "clean" unexpectedly in steps below:
      
          1. "repo.status()" is invoked (for status check before merging)
            1-1 "dirstate" entry for standinfile SF is "normal"-ed
            1-2 "lfdirstate" entry of largefile LF (for SF) is "normal"-ed
      
          2. "merge.update()" is invoked
            2-1 SF is updated in the working directory
                (ASSUMPTION: user choice "other" at conflict)
            2-2 "dirstate" entry for SF is "merge"-ed
      
          3. "lfcommands.updatelfiles()" is invoked (by "overrides.hgmerge()")
            3-1 largefile LF (for SF) is updated in the working directory
            3-2 "dirstate" returns "m" for SF (by 2-2)
            3-3 "lfdirstate" entry for LF is left as it is
            3-4 "lfdirstate" is written into ".hg/largefiles/dirstate", and
                timestamp of LF is stored into "lfdirstate" file (by 1-2)
                (ASSUMPTION: timestamp of LF differs from one of "lfdirstate" file)
      
      Then, "hs status" treats LF as "clean", even though LF is updated by
      "other" revision (by 3-1), because "lfilesrepo.status()" always treats
      "normal"-ed files (by 1-2 and 3-4) as "clean".
      
      When state of standinfile in "dirstate" is "m", largefile should be
      "normallookup"-ed.
      
      This patch invokes "normallookup" on "lfdirstate" for merged files.
      
      This patch uses "[debug] dirstate.delaywrite" feature in the test, to
      ensure that timestamp of the largefile gotten from "other" revision is
      stored into ".hg/largefiles/dirstate". (for ASSUMPTION at 3-4)
      8ecbe55f
    • Katsunori FUJIWARA's avatar
      largefiles: use "normallookup", if "mtime" of standin is unset · 21a2f31f
      Katsunori FUJIWARA authored
      Before this patch, largefiles gotten from "other" revision (without
      conflict) at "hg merge" become "clean" unexpectedly in steps below:
      
          1. "merge.update()" is invoked
            1-1 standinfile SF is updated in the working directory
            1-2 "dirstate" entry for SF is "normallookup"-ed
      
          2. "lfcommands.updatelfiles()" is invoked (by "overrides.hgmerge()")
            2-1 largefile LF (for SF) is updated in the working directory
            2-2 "dirstate" returns "n" for SF (by 1-2)
            2-3 "lfdirstate" entry for LF is "normal"-ed
            2-4 "lfdirstate" is written into ".hg/largefiles/dirstate", and
                timestamp of LF is stored into "lfdirstate" file
                (ASSUMPTION: timestamp of LF differs from one of "lfdirstate" file)
      
      Then, "hs status" treats LF as "clean", even though LF is updated by
      "other" revision (by 2-1), because "lfilesrepo.status()" always treats
      "normal"-ed files (by 2-3 and 2-4) as "clean".
      
      When timestamp is not set (= negative value) for standinfile in
      "dirstate", largefile should be "normallookup"-ed regardless of
      rebasing or not, because "n" state in "dirstate" doesn't ensure
      "clean"-ness of a standinfile at that time.
      
      This patch uses "normallookup" instead of "normal", if "mtime" of
      standin is unset
      
      This is a temporary way to fix with less changes. For fundamental
      resolution of this kind of problems in the future, "lfdirstate" should
      be updated with "dirstate" simultaneously while "merge.update"
      execution: maybe by hooking "recordupdates"
      
      It is also why this patch (temporarily) uses internal field "_map" of
      "dirstate" directly.
      
      This patch uses "[debug] dirstate.delaywrite" feature in the test, to
      ensure that timestamp of the largefile gotten from "other" revision is
      stored into ".hg/largefiles/dirstate". (for ASSUMPTION at 2-4)
      
      This patch newly adds "test-largefiles-update.t", to avoid increasing
      cost to run other tests for largefiles by subsequent patches
      (especially, "[debug] dirstate.delaywrite" causes so).
      21a2f31f
    • Katsunori FUJIWARA's avatar
      dirstate: delay writing out to ensure timestamp of each entries explicitly · 89b809fa
      Katsunori FUJIWARA authored
      Even though "dirstate.write()" is invoked explicitly after "normal"
      invocations, timestamp field of entries may be still "unset" in the
      "dirstate" file itself , because "pack_dirstate" drops it when it is
      equal to the timestamp of "dirstate" file itself.
      
      This can avoid overlooking modification of files, which are updated at
      same time in the second. But on the other hand, this may hide timing
      critical problems.
      
      For example, incorrect "normal"-ing (or lack of "normallookup"-ing on
      the already "normal"-ed entry) is visible only when:
      
        - the target file is modified in the working directory at T1, and
        - "dirstate" file is written out at T2 (!= T1)
      
      Otherwise, T1 is dropped by "pack_dirstate" in "dirstate.write()"
      invocation, and "unset" is stored into "dirstate" file.
      
      It often fails to reproduce problems from incorrect "normal"-ing by
      Mercurial testset, because automated actions in the small repository
      almost always causes that T1 and T2 are same.
      
      This patch adds the debug feature to delay writing out to ensure
      timestamp of each entries explicitly.
      
      This feature is used to make timing critical "dirstate" problems
      reproducable in subsequent patches.
      89b809fa
  18. Jul 21, 2014
  19. Jul 20, 2014
  20. Jul 19, 2014
Loading