Thu, 04 Sep 2014 19:05:36 +0200 groupbranchiter: support for non-contiguous revsets
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 04 Sep 2014 19:05:36 +0200] rev 23567
groupbranchiter: support for non-contiguous revsets The algorithm now works when some revisions are skipped. We now use "first included ancestors" instead of just "parent" to link changesets with each other.
Fri, 14 Nov 2014 20:08:59 +0000 groubranchhiter: indent most of the inner code
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 14 Nov 2014 20:08:59 +0000] rev 23566
groubranchhiter: indent most of the inner code We are going to add an additional layer of indentation to support non-contiguous revset. We do it in a pure code movement changeset to help the readability of the next changeset.
Fri, 14 Nov 2014 17:37:59 +0000 graphlog: add a way to test the 'groupbranchiter' function
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 14 Nov 2014 17:37:59 +0000] rev 23565
graphlog: add a way to test the 'groupbranchiter' function We add an experimental config option to use the topological sorting. I first tried to hook the 'groupbranchiter' function in the 'sort' revset but this was useless because graphlog enforces revision number sorting :( As the goal is to advance on the topological iteration logic, I see this experimental option as a good way to move forward. We have to use turn the iterator into a list because the graphlog is apparently not ready for pure iterator input yet.
Thu, 04 Sep 2014 18:19:32 +0200 graphmod: add a function for topological iteration
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 04 Sep 2014 18:19:32 +0200] rev 23564
graphmod: add a function for topological iteration This changeset introduces a function to perform topological (one branch after the other) iteration over a set of changesets. This first version has a lot of limitations, but the approach should be flexible enough to allow many improvements in the future. This changeset aims to set the first stone more than providing a complete solution. The algorithm does not need to know the whole set of nodes involved before emitting revision. This makes it a good candidate for usage in place like `hg log` or graphical tools that need a fast first result time.
(0) -10000 -3000 -1000 -300 -100 -30 -10 -4 +4 +10 +30 +100 +300 +1000 +3000 +10000 tip