Closed dabrahams closed 11 years ago
It would also be good to remove revision range restrictions where they don't actually make a difference. The less irrelevant information in the ruleset, the better.
I completely agree that the branches that are specific to a single repository do not belong in common_branches
and should be cleaned up.
Concerning revision ranges, I would prefer to keep (and extend) as much information as possible. If a common branch B is deleted at a particular revision, and a repository R has a minimum revision that is greater, no entry will be created in the patrie for branch B of repository R. I don't know how much the impact is on performance and memory consumption, but if we want to dump all entries in the patrie (possibly together with some statistics about how often a match succeeded), it might turn out valuable to have less superflous entries.
There's already code to dump all the entries. The result is vast, but getting things out of common_branches would probably help a lot to reduce that result
I don't expect any significant improvement in performance from revision limiting, and I suspect it will make editing a bit harder for people, which I think is way more important than performance/memory use. No?
I could fairly easily update analysis to warn about unused revision limitations, but unless we agree about them I'm not going to bother. We could of course do more, but since the branch rules with the poorest coverage have been eliminated, I'm going to close this.
For example, there are lots of branch rules in
common_branches
that really are specific to a given repository. It would greatly simplify thinking about how the rules work if these were localized to specific repository sections. If we wrote some post-processing code to dump information about branch rules that are only matched in a single repository, that would be easy to automate.