Skip to content
Snippets Groups Projects
  1. Apr 17, 2013
  2. Apr 16, 2013
  3. Apr 17, 2013
  4. Apr 16, 2013
    • Pierre-Yves David's avatar
      histedit: move outgoing processing to its own function · 26b41a90
      Pierre-Yves David authored
      Every piece of code extracted from the main command is a win. We simplify
      changeset determination in the process. Parent ceases being a list before
      becoming a node. We how have a root variable containing a node all the time.
      26b41a90
    • Pierre-Yves David's avatar
      histedit: move all arguments checks to the beginning of the command · 12c06686
      Pierre-Yves David authored
      This changeset move all checks and raises related to arguments
      validation to the top of the file. This gathers all the logic in one
      place and clarifies the code doing actual work. This paves the way for
      splitting this gigantic function in separated functions.
      
      A `goal` variable is introduced in the process. It holds the action to
      be done by this invocation (new, continue or abort).
      
      An invalid invocation is found in the process (the new code is a bit stricter).
      12c06686
  5. Apr 17, 2013
  6. Apr 16, 2013
    • Pierre-Yves David's avatar
      histedit: allow "-" as a command file · 730614b9
      Pierre-Yves David authored
      When "-" is specified as a command file, we read rules from stdin. Alter a
      single test to demo the behavior, but most of them could benefit from this.
      
      There is minor change in test output resulting from the fact we no
      longer change log messages.
      730614b9
    • Pierre-Yves David's avatar
      histedit: properly handle --continue on empty fold · c5c8613f
      Pierre-Yves David authored
      When all changes from the fold have been dropped, the --continue code was
      confused. This changeset handles this case.
      
      The test for this case existed but was broken.
      c5c8613f
    • Pierre-Yves David's avatar
      histedit-test: replace obscure python script by a plain file · 27ec54f2
      Pierre-Yves David authored
      One of the tests uses a python script to edit the histedit commands on
      the fly. It was hard to read and likely to break. This is replaced by
      a plain command file.
      
      Doing so made me discover that the python script is incorrect. The
      "+6" regexp never matched because the revision number is wrong.
      
      This error is kept in the replacement for now. Fixing the histedit command
      triggers a traceback in histedit.
      
      A later changeset will fix the error and restore the intended test.
      27ec54f2
    • Pierre-Yves David's avatar
      test: improve documentation of some histedit tests · 07db88f0
      Pierre-Yves David authored
      Each test section is clearly separated from the others and gains some
      helpful documentation.
      07db88f0
    • Pierre-Yves David's avatar
      test: use a lighter log style in histedit test · 7b50120e
      Pierre-Yves David authored
      The default log displays a log of information that is useless for
      histedit tests. Having a cleaner log help readability of those tests a
      lot.
      
      This does not change anything to the test semantic.
      7b50120e
  7. Apr 17, 2013
  8. Apr 16, 2013
  9. Apr 15, 2013
  10. Apr 16, 2013
    • Mads Kiilerich's avatar
      largefiles: getlfile must hit end of HTTP chunked streams to reuse connections · 0b3b8422
      Mads Kiilerich authored
      We did read the exactly the right number of bytes from the response body. But
      if the response came in chunked encoding then that meant that the HTTP layer
      still hadn't read the last 0-sized chunk and expected the app layer to read
      more data from the stream. The app layer was however happy and sent another
      request which had to be sent on another HTTP connection while the old one was
      lingering until some other event closed the connection.
      
      Adding an extra read where we expect to hit the end of file makes the HTTP
      connection ready for reuse. This thus plugs a real socket leak.
      
      To distinguish HTTP from SSH we look at self's class, just like it is done in
      putlfile.
      0b3b8422
  11. Apr 15, 2013
  12. Apr 09, 2013
    • Katsunori FUJIWARA's avatar
      summary: clear "commonincoming" also if branches are different · 4cf09a1b
      Katsunori FUJIWARA authored
      Before this patch, "commonincoming" calculated by
      "discovery.findcommonincoming()" is cleared, only if "default" URL
      without branch part (tail "#branch" of URL) differs from
      "default-push" URL without branch part.
      
      But common revisions in "commonincoming" calculated for a branch
      doesn't include ones for another branch, even if URLs without branch
      part are same. The result of "discovery.findcommonoutgoing()"
      invocation with such "commonincoming" becomes incorrect in some cases.
      
      This patch clears "commonincoming", also if branch part of "default"
      differs from one of "default-push".
      
      To avoid redundant looking up:
      
        - "ui.expandpath('default')" and "ui.expandpath('default-push',
          'default')" are not compared directly, even though they contain
          branch information, because they are not yet normalized by
          "hg.parseurl()": tail "/" of path, for example
      
        - "commonincoming" is not cleared, if branch isn't specified in
          "default" URL, because such "commonincoming" contains common
          revisions for all branches
      
      This patch also tests "different path, same branch" pattern to check
      careless degrading around comparison between source and destination.
      4cf09a1b
    • Katsunori FUJIWARA's avatar
      summary: make "incoming" information sensitive to branch in URL (issue3830) · 160d8416
      Katsunori FUJIWARA authored
      Before this patch, "incoming" information of "hg summary --remote" is
      not sensitive to the branch specified in the URL of the destination
      repository, even though "hg pull"/"hg incoming" are so.
      
      Invocation of "discovery.findcommonincoming()" without "heads"
      argument treats revisions on branches other than the one specified in
      the URL as incoming ones unexpectedly.
      
      This patch looks head revisions, which are already detected by
      "hg.addbranchrevs()" from URL, up against "other" repository, and
      invokes "discovery.findcommonincoming()" with list of them as "heads"
      to limit calculation of incoming revisions.
      160d8416
    • Katsunori FUJIWARA's avatar
      histedit: make "hg histedit" sensitive to branch in URL · 0023a6e4
      Katsunori FUJIWARA authored
      Before this patch, "hg histedit" are not sensitive to the branch
      specified in the URL of the destination repository, even though "hg
      push"/"hg outgoing" are so:
      
      Invocation of "discovery.findcommonoutgoing()" without "onlyheads"
      argument treats revisions on branches other than the one specified in
      the URL as outgoing ones unexpectedly.
      
      This patch specifies list of head revisions, which are already
      detected by "hg.addbranchrevs()" from URL and looked up against local
      repository, as "onlyheads" to "discovery.findcommonoutgoing()" to
      limit calculation of outgoing revisions.
      0023a6e4
    • Katsunori FUJIWARA's avatar
      summary: make "outgoing" information sensitive to branch in URL (issue3829) · 32843795
      Katsunori FUJIWARA authored
      Before this patch, "outgoing" information of "hg summary --remote" is
      not sensitive to the branch specified in the URL of the destination
      repository, even though "hg push"/"hg outgoing" are so:
      
      Invocation of "discovery.findcommonoutgoing()" without "onlyheads"
      argument treats revisions on branches other than the one specified in
      the URL as outgoing ones unexpectedly.
      
      This patch looks head revisions, which are already detected by
      "hg.addbranchrevs()" from URL, up against local repository, and
      invokes "discovery.findcommonoutgoing()" with list of them as
      "onlyheads" to limit calculation of outgoing revisions.
      32843795
  13. Mar 29, 2013
    • Katsunori FUJIWARA's avatar
      annotate: increase refcount of each revisions correctly (issue3841) · 0fd0612d
      Katsunori FUJIWARA authored
      Before this patch, refcount (managed in "needed") of parents of each
      revisions in "visit" is increased, only when parent is not annotated
      yet (examined by "p not in hist").
      
      But this causes less refcount of the revision like "A" in the tree
      below ("A" is assumed as the second parent of "C"):
      
          A --- B --- C
            \       /
             \-----/
      
      Steps of annotation for "C" in this case are shown below:
      
        1. for "C"
          1.1 increase refcount of "B"
          1.2 increase refcount of "A" (=> 1)
          1.3 defer annotation for "C"
      
        2. for "A"
          2.1 annotate for "A" (=> put result into "hist[A]")
          2.2 clear "pcache[A]" ("pcache[A] = []")
      
        3. for "B"
          3.1 not increase refcount of "A", because "A not in hist" is False
          3.2 annotate for "B"
          3.3 decrease refcount of "A" (=> 0)
          3.4 delete "hist[A]", even though "A" is still needed by "C"
          3.5 clear "pcache[B]"
      
        4. for "C", again
          4.1 not increase refcount of "B", because "B not in hist" is False
          4.2 increase refcount of "A" (=> 1)
          4.3 defer annotation for "C"
      
        5. for "A", again
          5.1 annotate for "A" (=> put result into "hist[A]", again)
          5.2 clear "pcache[A]"
      
        6. for "C", once again
          6.1 not increase refcount of "B", because "B not in hist" is False
          6.2 not increase refcount of "A", because "A not in hist" is False
          6.3 annotate for "C"
          6.4 decrease refcount of "A", and delete "hist[A]"
          6.5 decrease refcount of "B", and delete "hist[B]"
          6.6 clear "pcache[C]"
      
      At step (5.1), annotation for "A" mis-recognizes that all lines are
      created at "A", because "pcache[A]" already cleared at step (2.2)
      prevents from scanning ancestors of "A".
      
      So, annotation for "C" or its descendants loses information about "A"
      or its ancestors.
      
      The root cause of this problem is that refcount of "A" is decreased at
      step (3.3), even though it isn't increased at step (3.1).
      
      To increase refcount correctly, this patch increases refcount of each
      parents of each revisions:
      
        - regardless of "p not in hist" or not, and
        - only once for each revisions in "visit" (by "not pcached")
      
      In fact, this problem should occur only on legacy repositories in
      which a filelog includes the merging between the revision and its
      ancestor (as the second parent), because:
      
        - tree is scanned in depth-first
      
          without such merging, revisions in "visit" refer different
          revisions as parent each other
      
        - recent Mercurial doesn't allow such merging
      
          changelog and manifest can include such merging someway, but
          filelogs can't, because "localrepository._filecommit()" converts
          such merging request to linear history.
      
      This patch tests merging cases below: these cases are from filelog of
      "mercurial/commands.py" in the repository of Mercurial itself.
      
        - both parents are same
      
              10 --- 11 --- 12
                        \_/
      
              filelogrev: changesetid:
                10          00ea3613f82c
                11          fc4a6e5b5812
                12          4f802588cdfb
      
        - the second parent is also ancestor of the first one
      
              37 --- 38 --- 39 --- 40
                        \________/
      
              filelogrev: changesetid:
                37          f8d56da6ac8f
                38          38919e1c254d
                39          d3400605d246
                40          f06a4a3b86a7
      0fd0612d
    • Katsunori FUJIWARA's avatar
      annotate: reuse already calculated annotation · a54ddfae
      Katsunori FUJIWARA authored
      Before this patch, annotation is re-calculated even if it is already
      calculated. This may cause unexpected annotation, because already
      cleared "pcache" ("pcache[f] = []") prevents from scanning ancestors.
      
      This patch reuses already calculated annotation if it is available.
      
      In fact, "reusable" situation should be seen only on legacy
      repositories in which a filelog include the merging between the
      revision and its ancestor, because:
      
        - tree is scanned in depth-first
      
          without such merging, annotation result should be released soon
      
        - recent Mercurial doesn't allow such merging
      
          changelog and manifest can include such merging someway, but
          filelogs can't, because "localrepository._filecommit()" converts
          such merging request to linear history.
      a54ddfae
  14. Apr 16, 2013
Loading