subrepo: ensure "lock.release()" execution at the end of "storeclean()" Before this patch, "lock.release()" for "self._repo" in "storeclean()" of "hgsubrepo" may not be executed, if unexpected exception is raised, because it isn't executed in "finally" clause. This patch ensures "lock.release()" execution at the end of "storeclean()" by moving it into "finally" clause. This patch chooses moving almost all lines in "storeclean()" into "_storeclean()" instead of indenting them for "try/finally" clauses, to keep diff simple for review-ability.

largefiles: confirm existence of outgoing largefile entities in remote store Before this patch, "hg summary" and "hg outgoing" show and count up all largefiles changed/added in outgoing revisions, even though some of them are already uploaded into remote store. This patch confirms existence of outgoing largefile entities in remote store, to show and count up only really outgoing largefile entities at "hg summary" and "hg outgoing".

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()".

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.

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.

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.