Tue, 09 May 2017 15:08:47 +0200 hghave: prefill more version of Mercurial stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 09 May 2017 15:08:47 +0200] rev 32206
hghave: prefill more version of Mercurial The previous code was unable to go above version 4.0.
Thu, 11 May 2017 17:18:40 +0200 graft: fix graft across merges of duplicates of grafted changes stable
Mads Kiilerich <madski@unity3d.com> [Thu, 11 May 2017 17:18:40 +0200] rev 32205
graft: fix graft across merges of duplicates of grafted changes Graft used findmissingrevs to find the candidates for graft duplicates in the destination. That function operates with the constraint: 1. N is an ancestor of some node in 'heads' 2. N is not an ancestor of any node in 'common' For our purpose, we do however have to work correctly in cases where the graft set has multiple roots or where merges between graft ranges are skipped. The only changesets we can be sure doesn't have ancestors that are grafts of any changeset in the graftset, are the ones that are common ancestors of *all* changesets in the graftset. We thus need: 2. N is not an ancestor of all nodes in 'common' This change will graft more correctly, but it will also in some cases make graft slower by making it search through a bigger and unnecessary large sets of changes to find duplicates. In the general case of grafting individual or linear sets, we do the same amount of work as before.
Tue, 09 May 2017 00:11:30 +0200 graft: test coverage of grafts and how merges can break duplicate detection stable
Mads Kiilerich <madski@unity3d.com> [Tue, 09 May 2017 00:11:30 +0200] rev 32204
graft: test coverage of grafts and how merges can break duplicate detection This demonstrates unfortunate behaviour: extending the graft range cause the graft to behave differently. When the graft range includes a merge, we fail to detect duplicates that are ancestors of the merge.
Wed, 26 Apr 2017 22:05:59 +0900 mpatch: proxy through mdiff module
Yuya Nishihara <yuya@tcha.org> [Wed, 26 Apr 2017 22:05:59 +0900] rev 32203
mpatch: proxy through mdiff module See the previous commit for why.
Wed, 26 Apr 2017 22:03:37 +0900 bdiff: proxy through mdiff module
Yuya Nishihara <yuya@tcha.org> [Wed, 26 Apr 2017 22:03:37 +0900] rev 32202
bdiff: proxy through mdiff module See the previous commit for why. mdiff seems a good place to host bdiff functions. bdiff.bdiff was already aliased as textdiff, so we use it.
Wed, 26 Apr 2017 21:56:47 +0900 base85: proxy through util module
Yuya Nishihara <yuya@tcha.org> [Wed, 26 Apr 2017 21:56:47 +0900] rev 32201
base85: proxy through util module I'm going to replace hgimporter with a simpler import function, so we can access to pure/cext modules by name: # util.py base85 = policy.importmod('base85') # select pure.base85 or cext.base85 # cffi/base85.py from ..pure.base85 import * # may re-export pure.base85 functions This means we'll have to use policy.importmod() function in place of the standard import statement, but we wouldn't want to write it every place where C extension modules are used. So this patch makes util host base85 functions.
Tue, 02 May 2017 17:05:22 +0900 mdiff: move re-exports to top
Yuya Nishihara <yuya@tcha.org> [Tue, 02 May 2017 17:05:22 +0900] rev 32200
mdiff: move re-exports to top This style seems more common in our codebase.
Tue, 02 May 2017 19:10:55 +0900 test-commit-interactive-curses: remove unused import of parsers
Yuya Nishihara <yuya@tcha.org> [Tue, 02 May 2017 19:10:55 +0900] rev 32199
test-commit-interactive-curses: remove unused import of parsers
Mon, 08 May 2017 23:05:01 -0400 churn: use the non-deprecated template option in the examples stable
Matt Harbison <matt_harbison@yahoo.com> [Mon, 08 May 2017 23:05:01 -0400] rev 32198
churn: use the non-deprecated template option in the examples
Mon, 08 May 2017 11:35:23 -0700 strip: make tree stripping O(changes) instead of O(repo)
Durham Goode <durham@fb.com> [Mon, 08 May 2017 11:35:23 -0700] rev 32197
strip: make tree stripping O(changes) instead of O(repo) The old tree stripping logic iterated over every tree revlog in the repo looking for commits that had revs to be stripped. That's very inefficient in large repos. Instead, let's look at what files are touched by the strip and only inspect those revlogs. I don't have actual perf numbers, since internally we don't use a true treemanifest, but simply iterating over hundreds of thousands of revlogs takes many, many seconds, so this should help tremendously when stripping only a few commits.
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip