Mon, 07 Jul 2014 18:45:46 +0900 largefiles: show also how many data entities are outgoing at "hg outgoing"
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 07 Jul 2014 18:45:46 +0900] rev 21883
largefiles: show also how many data entities are outgoing at "hg outgoing" Before this patch, "hg outgoing --large" shows which largefiles are changed or added in outgoing revisions only in the point of the view of filenames. For example, according to the list of outgoing largefiles shown in "hg outgoing" output, users should expect that the former below costs much more to upload outgoing largefiles than the latter. - outgoing revisions add a hundred largefiles, but all of them refer the same data entity in this case, only one data entity is outgoing, even though "hg summary" says that a hundred largefiles are outgoing. - a hundred outgoing revisions change only one largefile with distinct data in this case, a hundred data entities are outgoing, even though "hg summary" says that only one largefile is outgoing. But the latter costs much more than the former, in fact. This patch shows also how many data entities are outgoing at "hg outgoing" by counting number of unique hash values for outgoing largefiles. When "--debug" is specified, this patch also shows what entities (in hash) are outgoing for each largefiles listed up, for debug purpose. In "ui.debugflag" route, "addfunc()" can append given "lfhash" to the list "toupload[fn]" always without duplication check, because de-duplication is already done in "_getoutgoings()".
Mon, 07 Jul 2014 18:45:46 +0900 largefiles: show also how many data entities are outgoing at "hg summary"
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 07 Jul 2014 18:45:46 +0900] rev 21882
largefiles: show also how many data entities are outgoing at "hg summary" Before this patch, "hg summary --large" shows how many largefiles are changed or added in outgoing revisions only in the point of the view of filenames. For example, according to the number of outgoing largefiles shown in "hg summary" output, users should expect that the former below costs much more to upload outgoing largefiles than the latter. - outgoing revisions add a hundred largefiles, but all of them refer the same data entity in this case, only one data entity is outgoing, even though "hg summary" says that a hundred largefiles are outgoing. - a hundred outgoing revisions change only one largefile with distinct data in this case, a hundred data entities are outgoing, even though "hg summary" says that only one largefile is outgoing. But the latter costs much more than the former, in fact. This patch shows also how many data entities are outgoing at "hg summary" by counting number of unique hash values for outgoing largefiles. This patch introduces "_getoutgoings" to centralize the logic (de-duplication, too) into it for convenience of subsequent patches, even though it is not required in "hg summary" case.
Mon, 07 Jul 2014 18:45:46 +0900 largefiles: add tests for summary/outgoing improved in subsequent patches
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 07 Jul 2014 18:45:46 +0900] rev 21881
largefiles: add tests for summary/outgoing improved in subsequent patches This patch adds tests for summary/outgoing improved in subsequent patches, to reduce amount of diffs in each patches. This patch adds new revisions below: - revision #2 adds new largefiles, but they contain as same data as one already existing this causes that multiple standins refer the same data entity - revision #3, #4 and #5 change the already existing largefile this causes that multiple data entities are outgoing for the standin. #5 can be used to check de-duplication of "(hash, filename)" pair.
Sat, 12 Jul 2014 17:59:03 -0700 context: generate filtered manifest efficiently for exact matchers
Siddharth Agarwal <sid0@fb.com> [Sat, 12 Jul 2014 17:59:03 -0700] rev 21880
context: generate filtered manifest efficiently for exact matchers When the matcher is exact, there's no reason to iterate over the entire manifest. It's much more efficient to iterate over the list of files instead. For a repository with approximately 300,000 files, this speeds up hg log -l10 --patch --follow for a frequently modified file from 16.5 seconds to 10.5 seconds.
Sat, 12 Jul 2014 17:57:25 -0700 manifestdict: add a new method to intersect with a set of files
Siddharth Agarwal <sid0@fb.com> [Sat, 12 Jul 2014 17:57:25 -0700] rev 21879
manifestdict: add a new method to intersect with a set of files This is meant to be used when the set of files is known in advance, e.g. with a match object with no patterns.
Sat, 12 Jul 2014 18:31:18 -0700 log: use an exact matcher for --patch --follow
Siddharth Agarwal <sid0@fb.com> [Sat, 12 Jul 2014 18:31:18 -0700] rev 21878
log: use an exact matcher for --patch --follow The arguments to log --patch --follow are expected to be exact paths. This will be used to make manifest filtering for these cases more efficient in upcoming patches.
Wed, 16 Jul 2014 17:35:04 -0500 merge with stable
Matt Mackall <mpm@selenic.com> [Wed, 16 Jul 2014 17:35:04 -0500] rev 21877
merge with stable
Sat, 12 Jul 2014 02:23:17 -0700 log: make --patch --follow work inside a subdirectory stable
Siddharth Agarwal <sid0@fb.com> [Sat, 12 Jul 2014 02:23:17 -0700] rev 21876
log: make --patch --follow work inside a subdirectory Previously, the 'patch' code for hg log --patch --follow would try to resolve patterns relative to the repository root rather than the current working directory. Fix that by using match.files instead of pats, as done elsewhere nearby.
(0) -10000 -3000 -1000 -300 -100 -30 -10 -8 +8 +10 +30 +100 +300 +1000 +3000 +10000 +30000 tip