largefiles: getlfile must hit end of HTTP chunked streams to reuse connections 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.

largefiles: drop limitreader, use filechunkiter limit filechunkiter.close was a noop.

largefiles: move protocol conversion into getlfile and make it an iterable Avoid the intermediate limitreader and filechunkiter between getlfile and copyandhash - return the right protocol and put the complexity where it better can be managed.

largefiles: don't close the fd passed to store._getfile

largefiles: remove blecch from lfutil.copyandhash - don't close the passed fd

largefiles: drop lfutil.blockstream - use filechunkiter like everybody else The old chunk size is kept - just to avoid changing it.

largefiles: refactoring - use findfile in localstore._getfile

largefiles: refactoring - return hex from _getfile and copyandhash

largefiles: refactoring - create destination dir in lfutil.link

summary: clear "commonincoming" also if branches are different 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.

summary: make "incoming" information sensitive to branch in URL (issue3830) 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.

histedit: make "hg histedit" sensitive to branch in URL 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.

summary: make "outgoing" information sensitive to branch in URL (issue3829) 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.

annotate: increase refcount of each revisions correctly (issue3841) 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

annotate: reuse already calculated annotation 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.

log: fix behavior with empty repositories (issue3497) Make output in this special case consistent with general case one.

merge with crew

revlog: don't cross-check ancestor result against Python version

parsers: a C implementation of the new ancestors algorithm 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.)

revlog: choose a consistent ancestor when there's a tie 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.

ancestor: a new algorithm that is faster for nodes near tip 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.

update: allow dirty update to foreground (successors) 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.

obsolete: extract foreground computation from bookmark.validdest This foreground logic will be reused by update logic.

destroyed: invalidate phraserevs cache in all case (issue3858) 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.

largefiles: deprecate --all-largefiles for pull The same can be achieved with --lfrev pulled() and we shouldn't advertise unnecessary command line options.

largefiles: implement pull --all-largefiles as a special case of --lfrev

largefiles: drop --cache-largefiles again This goes a step further than d69585a5c5c0 and backs out the unreleased --cache-largefiles option. The same can be achieved with --lfrev heads(pulled()) and we shouldn't introduce unnecessary command line options.

largefiles: introduce pulled() revset expression for use in --lfrev This provides a general way to do what already can be done with --all-largefiles and --cache-largefiles.

largefiles: introduce pull --lfrev option The revset will be evaluated after the changesets has been pulled, and missing largefiles from matching revisions will be pulled to the local caches. This in combination with revsets will make it possible to specify different strategies for pulling largefiles. The revset expressions used for this option might be quite complex and will probably be most useful from scripts or an alias ... but less complicated than configuring hooks.

largefiles: refactor overridepull internals