Tue, 28 Mar 2017 06:38:09 +0200 track-tags: introduce first bits of tags tracking during transaction
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 28 Mar 2017 06:38:09 +0200] rev 31994
track-tags: introduce first bits of tags tracking during transaction This changeset introduces detection of tags changes during transaction. When this happens a 'tag_moved=1' argument is set for hooks, similar to what we do for bookmarks and phases. This code is disabled by default as there are still various performance concerns. Some require a smarter use of our existing tag caches and some other require rework around the transaction logic to skip execution when unneeded. These performance improvements have been delayed, I would like to be able to experiment and stabilize the feature behavior first. Later changesets will push the concept further and provide a way for hooks to know what are the actual changes introduced by the transaction. Similar work is needed for the other families of changes (bookmark, phase, obsolescence, etc). Upgrade of the transaction logic will likely be performed at the same time. The current code can report some false positive when .hgtags file changes but resulting tags are unchanged. This will be fixed in the next changeset. For testing, we simply globally enable a hook in the tag test as all the possible tag update cases should exist there. A couple of them show the false positive mentioned above. See in code documentation for more details.
Tue, 28 Mar 2017 05:06:56 +0200 tags: introduce a function to return a valid fnodes list from revs
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 28 Mar 2017 05:06:56 +0200] rev 31993
tags: introduce a function to return a valid fnodes list from revs This will get used to compare tags between two set of revisions during a transaction (pre and post heads). The end goal is to be able to track tags movement in transaction hooks.
Fri, 14 Apr 2017 14:25:06 +0200 context: possibly yield initial fctx in blockdescendants()
Denis Laxalde <denis.laxalde@logilab.fr> [Fri, 14 Apr 2017 14:25:06 +0200] rev 31992
context: possibly yield initial fctx in blockdescendants() If initial 'fctx' has changes in line range with respect to its parents, we yield it first. This makes 'followlines(..., descend=True)' consistent with 'descendants()' revset which yields the starting revision. We reuse one iteration of blockancestors() which does exactly what we want. In test-annotate.t, adjust 'startrev' in one case to cover the situation where the starting revision does not touch specified line range.
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -3 +3 +10 +30 +100 +300 +1000 +3000 +10000 tip