Skip to content
Snippets Groups Projects
  1. Oct 01, 2014
  2. Sep 30, 2014
  3. Sep 22, 2014
  4. Sep 30, 2014
  5. Sep 27, 2014
    • Anton Shestakov's avatar
      hgweb: refresh hgweb.repo on phase change (issue4061) · a111e460
      Anton Shestakov authored
      Make hgweb.refresh() also look at phaseroots file (in addition to 00changelog.i
      file) and reload the repo when os.stat returns different mtime or size than
      cached, signifying the file was modified.
      
      This way if user changes phase of a changeset (secret <-> draft), there's no
      need to restart hg serve to see the change.
      a111e460
  6. Sep 29, 2014
  7. Sep 22, 2014
    • Anton Shestakov's avatar
      hgweb: fail if an invalid command was supplied in url path (issue4071) · 6e1fbcb1
      Anton Shestakov authored
      Traditionally, the way to specify a command for hgweb was to use url query
      arguments (e.g. "?cmd=batch"). If the command is unknown to hgweb, it gives an
      error (e.g. "400 no such method: badcmd").
      
      But there's also another way to specify a command: as a url path fragment (e.g.
      "/graph"). Before, hgweb was made forgiving (looks like it was made in
      44c5157474e7) and user could put any unknown command in the url. If hgweb
      couldn't understand it, it would just silently fall back to the default
      command, which depends on the actual style (e.g. for paper it's shortlog, for
      monoblue it's summary). This was inconsistent and was breaking some tools that
      rely on http status codes (as noted in the issue4071). So this patch changes
      that behavior to the more consistent one, i.e. hgweb will now return "400 no
      such method: badcmd".
      
      So if some tool was relying on having an invalid command return http status
      code 200 and also have some information, then it will stop working. That is, if
      somebody typed foobar when they really meant shortlog (and the user was lucky
      enough to choose a style where the default command is shortlog too), that fact
      will now be revealed.
      
      Code-wise, the changed if block is only relevant when there's no "?cmd" query
      parameter (i.e. only when command is specified as a url path fragment), and
      looks like the removed else branch was there only for falling back to default
      command. With that removed, the rest of the code works as expected: it looks at
      the command, and if it's not known, raises a proper ErrorResponse exception
      with an appropriate message.
      
      Evidently, there were no tests that required the old behavior. But, frankly, I
      don't know any way to tell if anyone actually exploited such forgiving behavior
      in some in-house tool.
      6e1fbcb1
  8. Sep 24, 2014
    • Mike Hommey's avatar
      keepalive: fix how md5 is used · 232d437a
      Mike Hommey authored
      The code in keepalive dates from when it was importing the md5 module directly
      and uses md5.new. Since then, what 'md5' means has been changed from an import
      of the md5 module to being a function using the right module between hashlib
      and md5, so the md5.new idiom doesn't work anymore.
      232d437a
  9. Sep 17, 2014
    • Pierre-Yves David's avatar
      revset: add an optimised baseset.__contains__ (issue4371) · 300e0758
      Pierre-Yves David authored
      The baseset class is based on a python list. This means that base.__contains__
      was absolutely as crappy as list.__contains__. We now rely on __contains__ from
      the underlying set.
      
      This will avoid having to explicitly convert the baseset to a set (using
      baseset.set()) whenever one want fast membership test.
      
      Apparently there is already code that forgot to do such conversions since we
      observe a massive speedup in some test.
      
      revset #25: roots((0::) - (0::tip))
      0) wall 2.079454 comb 2.080000 user 2.080000 sys 0.000000 (best of 5)
      1) wall 0.132970 comb 0.130000 user 0.130000 sys 0.000000 (best of 65)
      
      No regression is observed in benchmarks.
      
      This change improve the issue4371 back to acceptable situation (but are still
      slower than manual substraction)
      300e0758
  10. Sep 21, 2014
  11. Sep 11, 2014
    • Katsunori FUJIWARA's avatar
      mq: examine "pushable" of already applied patch correctly · 4bbcee18
      Katsunori FUJIWARA authored
      Before this patch, "hg qselect" with --pop/--reapply may pop patches
      unexpectedly, even when all of patches applied before "qselect" are
      still pushable.
      
      Strictly speaking about the condition of this issue:
      
        - before "qselect"
          - there are N applied patches
          - the index of the guarded patch X in the series is less than N
      
        - after "qselect"
          - X is still guarded, and
          - all of applied patched are still pushable
      
      In the case above, "hg qselect" should keep current status, but it
      actually tries to pop patches because of X.
      
      The index in "the series" should be used to examine "pushable" of a
      patch by "mq.pushablek()", but the index in "applied patches" is used,
      and this may cause unexpected examination of guarded patch.
      
      To examine "pushable" of already applied patch correctly, this patch
      uses "mq.applied[i].name": "pushable" is the function introduced by
      the previous patch, and it returns "mq.pushable(mq.applied[i].name)[0]".
      4bbcee18
    • Katsunori FUJIWARA's avatar
      mq: pop correct patches when changing pushable-ness of already applied ones · c89379d4
      Katsunori FUJIWARA authored
      Before this patch, "hg qselect" with --pop/--reapply may pop incorrect
      patches, because the index in "applied patches" is used to pop patches
      by "mq.pop()", even though the index in "the series" should be used.
      
      For example, when the already applied patch becomes guarded and it
      follows the already guarded (= not yet applied) one, "hg qselect" is
      aborted, because it tries to pop to guarded one.
      
      This patch uses "mq.applied[i - 1].name" to pop to the patch, of which
      the index in the "applied ones" is "i - 1".
      c89379d4
    • Katsunori FUJIWARA's avatar
      mq: use "mq.applied[i].name" instead of "mq.appliedname(i)" for safety · ac31d876
      Katsunori FUJIWARA authored
      Before this patch, "hg qselect --reapply" is aborted when "--verbose"
      is specified, because "mq.appliedname()" returns "INDEX PATCHNAME"
      instead of "PATCHNAME" in such case and "mq.push" can't accept the
      former as the name of patch.
      
      This patch uses "mq.applied[i].name" instead of "mq.appliedname(i)" as
      the name of the patch to be pushed for safety.
      
      Now, there is no code path using "mq.appliedname()", and it should be
      removed to prevent developers from using it in the wrong way like this
      issue.
      ac31d876
    • Katsunori FUJIWARA's avatar
      mq: report correct numbers for changing "number of guarded, applied patches" · fd0f0b0d
      Katsunori FUJIWARA authored
      Before this patch, "hg qselect" may report incorrect numbers for
      "number of guarded, applied patches has changed", because it examines
      "pushable" of patches by the index not in "the series" but in "applied
      patches", even though "mq.pushable()" expects the former.
      
      To report correct numbers for changing "number of guarded, applied
      patches", this patch uses the name of applied patch to examine
      pushable-ness of it.
      
      This patch also changes the result of existing "hg qselect" tests,
      because they doesn't change pushable-ness of already applied patches.
      
      This patch assumes that "hg qselect" focuses on changing pushable-ness
      only of already applied patches, because:
      
        - the report message uses not "previous" (in the series) but
          "applied"
      
        - the logic to pop patches for --pop/--reapply examines
          pushable-ness only of already applied ones (in fact, there are
          some incorrect code paths)
      fd0f0b0d
  12. Sep 09, 2014
    • Katsunori FUJIWARA's avatar
      dispatch: check shell alias again after loading extensions (issue4355) · f98abe31
      Katsunori FUJIWARA authored
      Before this patch, the shell alias causes failure when it takes its
      specific (= unknown for "hg") options in the command line, because
      "_parse()" can't accept them.
      
      This is the regression introduced by 03d345da0579.
      
      It fixed the issue that ambiguity between shell aliases and commands
      defined by extensions was ignored. But it also caused that ambiguous
      shell alias is handled in "_parse()" even if it takes specific options
      in the command line.
      
      To avoid such failure, this patch checks shell alias again after
      loading extensions.
      
      All aliases and commands (including ones defined by extensions) are
      completely defined before the 2nd (= newly added in this patch)
      "_checkshellalias()" invocation, and "cmdutil.findcmd(strict=False)"
      can detect ambiguity between them correctly.
      
      For efficiency, this patch does:
      
        - omit the 2nd "_checkshellalias()" invocation if "[ui] strict= True"
      
          it causes "cmdutil.findcmd(strict=True)", of which result should
          be equal to one of the 1st invocation before adding aliases
      
        - avoid removing the 1st "_checkshellalias()" invocation
      
          it causes "cmdutil.findcmd(strict=True)" invocation preventing
          shell alias execution from loading extensions uselessly
      f98abe31
    • Katsunori FUJIWARA's avatar
      dispatch: make "_checkshellalias" reusable regardless of adding aliases · d821fff9
      Katsunori FUJIWARA authored
      To reduce changes in the subsequent patch fixing issue4355, this patch
      makes "_checkshellalias" reusable regardless of adding aliases.
      
      In this patch, alias definitions are added and restored, only when
      "precheck=True".
      d821fff9
  13. Sep 03, 2014
  14. Sep 02, 2014
  15. Sep 01, 2014
  16. Aug 30, 2014
    • Gregory Szorc's avatar
      help: only call doc() when it is callable · e284de13
      Gregory Szorc authored
      `hg help -k` on my machine was aborting because the hg-prompt extension
      was inserting a string and not a function into help.helptable and help
      was blindly calling it.
      
      This patch changes keyword searching to be more robust against
      unexpected types.
      e284de13
  17. Sep 01, 2014
  18. Aug 31, 2014
  19. Aug 30, 2014
  20. Aug 31, 2014
    • Mike Hommey's avatar
      repoview: fix typo in repoview.changelog · e1d5fcab
      Mike Hommey authored
      Incidentally, this avoids the changelog cache being invalidated each time
      it's accessed on a repoview.
      
      On a filtering experiment on a repository the size of mozilla-central,
      this makes a significant difference:
      
      Before, running hg log -l 10 --time with about 8k changesets filtered out:
      time: real 1.490 secs (user 1.450+0.000 sys 0.040+0.000)
      
      After:
      time: real 0.540 secs (user 0.530+0.000 sys 0.010+0.000)
      e1d5fcab
  21. Aug 19, 2014
  22. Aug 30, 2014
  23. Aug 27, 2014
    • Katsunori FUJIWARA's avatar
      import: show the warning message for failure of merging · 0c838e74
      Katsunori FUJIWARA authored
      Before this patch, no message is shown for failure of merging at "hg
      import".
      
      In such case, merging patch is imported as a normal revision silently,
      and it may confuse users.
      
      For simplicity, this patch recommends just using "--exact", even
      though importing the merging patch itself is possible without it if:
      
        - the hash of the 1st parent in the patch is equal to one of the
          patch imported just before (or the parent of the working
          directory, for the 1st patch of the series), and
      
        - the hash of the 2nd parent in the patch is known in the local
          repository
      0c838e74
    • Mads Kiilerich's avatar
      graft: fix collision detection with origin revisions that are missing · 9472284d
      Mads Kiilerich authored
      When grafting something with a matching origin, it would normally be skipped:
        skipping already grafted revision 123 (23 also has origin 12)
      
      But after stripping a graft origin, graft could fail with a reference to the
      origin that no longer exists:
        abort: unknown revision '5c095ad7e90f871700f02dd1fa5012cb4498a2d4'!
      
      Instead, detect that the origin is unknown and skip it anyway, like:
        skipping already grafted revision 8 (2 also has unknown origin 5c095ad7e90f871700f02dd1fa5012cb4498a2d4)
      9472284d
  24. Aug 23, 2014
  25. Aug 25, 2014
  26. Aug 15, 2014
Loading