quark added a comment.
In https://phab.mercurial-scm.org/D451#7257, @yuja wrote: > We could change this policy so all predicates must "define" their own ordering > schemes (as you did, I think), but I guess that would lead to bugs that are hardly > noticed. I think the current way is easier to hide bugs if more revset's `defineorder` is not the default (ascending). For example, I think `p1(X+Y)` could be naturally parsed as `p1(X) + p1(Y)` so it is not equivalent to `p1(Y+X)`. But the current code relies heavily on default ascending order and could not implement that easily. (This series does not change `p1` behavior, it's just a possibility) My understanding about `anyorder` is, we can random-shuffle `anyorder` sets without affecting correctness - I had tried that approach and it did reveal issues (like "contains" does not respect "defineorder"). But I found https://phab.mercurial-scm.org/D456 to be a stronger test about ordering issues. > So I'm against to bring more "any" ordering without noticeable > performance win. Can you measure it? Probably hard to measure. I think with the new suggested code pattern (either taking `subset` and `order`, or take none of them), it's harder to implement wrong. REPOSITORY rHG Mercurial REVISION DETAIL https://phab.mercurial-scm.org/D451 To: quark, #hg-reviewers Cc: yuja, mercurial-devel _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
