Mon, 15 Apr 2013 23:43:44 +0200 largefiles: drop lfutil.blockstream - use filechunkiter like everybody else
Mads Kiilerich <madski@unity3d.com> [Mon, 15 Apr 2013 23:43:44 +0200] rev 19001
largefiles: drop lfutil.blockstream - use filechunkiter like everybody else The old chunk size is kept - just to avoid changing it.
Mon, 15 Apr 2013 23:35:43 +0200 largefiles: refactoring - use findfile in localstore._getfile
Mads Kiilerich <madski@unity3d.com> [Mon, 15 Apr 2013 23:35:43 +0200] rev 19000
largefiles: refactoring - use findfile in localstore._getfile
Mon, 15 Apr 2013 23:35:18 +0200 largefiles: refactoring - return hex from _getfile and copyandhash
Mads Kiilerich <madski@unity3d.com> [Mon, 15 Apr 2013 23:35:18 +0200] rev 18999
largefiles: refactoring - return hex from _getfile and copyandhash
Mon, 15 Apr 2013 23:32:33 +0200 largefiles: refactoring - create destination dir in lfutil.link
Mads Kiilerich <madski@unity3d.com> [Mon, 15 Apr 2013 23:32:33 +0200] rev 18998
largefiles: refactoring - create destination dir in lfutil.link
Tue, 09 Apr 2013 23:40:11 +0900 summary: clear "commonincoming" also if branches are different
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 09 Apr 2013 23:40:11 +0900] rev 18997
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.
Tue, 09 Apr 2013 23:40:11 +0900 summary: make "incoming" information sensitive to branch in URL (issue3830)
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 09 Apr 2013 23:40:11 +0900] rev 18996
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.
(0) -10000 -3000 -1000 -300 -100 -30 -10 -6 +6 +10 +30 +100 +300 +1000 +3000 +10000 +30000 tip