Skip to content
Snippets Groups Projects
  1. Apr 17, 2013
  2. Apr 16, 2013
  3. Apr 15, 2013
  4. 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
  5. Apr 15, 2013
  6. 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
  7. 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
  8. Apr 16, 2013
    • Alexander Plavin's avatar
      log: fix behavior with empty repositories (issue3497) · c1af1fb3
      Alexander Plavin authored
      Make output in this special case consistent with general case one.
      c1af1fb3
    • Matt Mackall's avatar
      merge with crew · 7373be70
      Matt Mackall authored
      7373be70
    • Bryan O'Sullivan's avatar
    • Bryan O'Sullivan's avatar
      parsers: a C implementation of the new ancestors algorithm · 5bae9367
      Bryan O'Sullivan authored
      The performance of both the old and new Python ancestor algorithms
      depends on the number of revs they need to traverse.  Although the
      new algorithm performs far better than the old when revs are
      numerically and topologically close, both algorithms become slow
      under other circumstances, taking up to 1.8 seconds to give answers
      in a Linux kernel repo.
      
      This C implementation of the new algorithm is a fairly straightforward
      transliteration.  The only corner case of interest is that it raises
      an OverflowError if the number of GCA candidates found during the
      first pass is greater than 24, to avoid the dual perils of fixnum
      overflow and trying to allocate too much memory.  (If this exception
      is raised, the Python implementation is used instead.)
      
      Performance numbers are good: in a Linux kernel repo, time for "hg
      debugancestors" on two distant revs (24bf01de7537 and c2a8808f5943)
      is as follows:
      
        Old Python: 0.36 sec
        New Python: 0.42 sec
        New C: 0.02 sec
      
      For a case where the new algorithm should perform well:
      
        Old Python: 1.84 sec
        New Python: 0.07 sec
        New C: measures as zero when using --time
      
      (This commit includes a paranoid cross-check to ensure that the
      Python and C implementations give identical answers. The above
      performance numbers were measured with that check disabled.)
      5bae9367
    • Bryan O'Sullivan's avatar
      revlog: choose a consistent ancestor when there's a tie · 3605d4e7
      Bryan O'Sullivan authored
      Previously, we chose a rev based on numeric ordering, which could
      cause "the same merge" in topologically identical but numerically
      different repos to choose different merge bases.
      
      We now choose the lexically least node; this is stable across
      different revlog orderings.
      3605d4e7
    • Bryan O'Sullivan's avatar
      ancestor: a new algorithm that is faster for nodes near tip · 2f718640
      Bryan O'Sullivan authored
      Instead of walking all the way to the root of the DAG, we generate
      a set of candidate GCA revs, then figure out which ones will win
      the race to the root (usually without needing to traverse all the
      way to the root).
      
      In the common case of nodes that are close to each other in both
      revision number and topology, this is usually a big win: it makes
      "hg --time debugancestors" up to 9 times faster than the more general
      ancestor function when measured on heads of the linux-2.6 hg repo.
      
      Victory is not assured, however. The older function can still win
      by a large margin if one node is much closer to the root than the
      other, or by a much smaller amount if one is an ancestor of the
      other.
      
      For now, we've also got a small paranoid harness function that calls
      both ancestor functions on every input and ensures that they give
      equivalent answers.
      
      Even without the checker function, the old ancestor function needs
      to stay alive for the time being, as its generality is used by
      context.filectx.merge.
      2f718640
    • Pierre-Yves David's avatar
      update: allow dirty update to foreground (successors) · a59e575c
      Pierre-Yves David authored
      Update to "foreground" are no longer seen as cross branch update. "Foreground"
      are descendants or successors (or successors of descendants (or descendant of
      successors (etc))). This allows to update with uncommited changes that get
      automatically merged.
      
      This changeset is a small step forward. We want to allow dirty update to
      "background" (precursors) and takes obsolescence in account when finding the
      default update destination. But those requires deeper changes and will comes in
      later changesets.
      a59e575c
    • Pierre-Yves David's avatar
      obsolete: extract foreground computation from bookmark.validdest · efef056b
      Pierre-Yves David authored
      This foreground logic will be reused by update logic.
      efef056b
  9. Apr 15, 2013
    • Pierre-Yves David's avatar
      destroyed: invalidate phraserevs cache in all case (issue3858) · 31bcc511
      Pierre-Yves David authored
      When revisions are destroyed, the `phaserevs` cache becomes invalid in most case.
      This cache hold a `{rev => phase}` mapping and revision number most likely
      changed.
      
      Since 1c8e0d6ac3b0, we filter unknown phases' roots after changesets
      destruction.  When some roots are filtered the `phaserevs` cache is invalidated.
      But not if none root where destroyed.
      
      We now invalidate the cache in all case filtered root or not.
      
      This bug was a bit tricky to reproduce as in most case we either:
      * rebase a set a draft changeset including root (phaserev invalidated)
      * strip tip-most changesets (no re-numbering of revision)
      
      Note that the invalidation of `phaserevs` are not strictly needed when only
      tip-most part of the history have been destroyed. But I do not expect the
      overhead to be significant.
      31bcc511
  10. Apr 14, 2013
Loading