tests: simplify and document the sorting of pyflake messages
The pyflake messages are simply ordered by message type, path, line no (and
message text).
The message type is taken from the order of the filters.
The previous ordering looks complicated and illogically.
It was the following order (r'\3:\5:\4:\1:\2:' + line):
message (\3 and \5)
var name (\4)
path (\1)
line no (\2)
line reference
Ordering by var name before path looks illogically for me.
bundle: move file chunk generation to it's own function
Moves the file chunk generation part of bundle creation to it's own function.
This allows extensions to customize the filelog part of bundle generation.
parents: change parents command to use filectx
Changes the parents command to use filectx to look up the change node
instead of doing it manually. This allows extensions to modify the
file-to-commit relationship behind the filectx api.
update: remove .hg/graftstate on clean (
issue3970)
e078ea9b4ce4 introduced a check for interrupted grafts while committing. This
exposed a bug where hg update --clean didn't remove that file.
i18n-pt_BR: synchronized with
b500a663a2c7
templater: add strip function with chars as an extra argument
This allows specifying characters to strip, like the Python strip function.
revlog: add exception when linkrev == nullrev
When we deployed the latest crew mercurial to our users, a few of them
had issues where a filelog would have an entry with a -1 linkrev. This
caused operations like rebase and amend to create a bundle containing the
entire repository, which took a long time.
I don't know what the issue is, but adding this check should prevent repos
from getting in this state, and should help us pinpoint the issue next time
it happens.
revlog: add exception when linkrev == nullrev
When we deployed the latest crew mercurial to our users, a few of them
had issues where a filelog would have an entry with a -1 linkrev. This
caused operations like rebase and amend to create a bundle containing the
entire repository, which took a long time.
I don't know what the issue is, but adding this check should prevent repos
from getting in this state, and should help us pinpoint the issue next time
it happens.