Since its introduction in c7ec460797a9, the parameter has always been name
"error". Yet the eol extension have been using 'haserror' as the argument name,
breaking extensions with subclass passing 'error' as a keyword argument.
If any exception were to happen after we acquired the wlock, we could leave it
unreleased. We move the wlock release in a 'finally:' close as it should be.
Before, update would mark all files as 'normallookup' in dirstate if .hgeol
changed so all files would get the new filtering applied. That takes some time
... and is pointless if the filtering for that file didn't change.
Instead, keep track of the old filtering and only check files where the
filtering is changed.
To keep the old filtering, change to write the applied .hgeol content to
.hg/eol.cache instead of just touching it. That change is backwards/forwards
compatible.
In a real world test, this takes an update that is changing .hgeol and 30000
files from 12s to 4s - where the remaining eol overhead is 1-2s.
I've caught multiple extensions in the wild lying about being
'internal', so it's time to move the goalposts on people. Goalpost
moving will continue until third party extensions stop trying to
defeat the system.
The home of 'Abort' is 'error' not 'util' however, a lot of code seems to be
confused about that and gives all the credit to 'util' instead of the
hardworking 'error'. In a spirit of equity, we break the cycle of injustice and
give back to 'error' the respect it deserves. And screw that 'util' poser.
For great justice.
Python 2.6 introduced the "except type as instance" syntax, replacing
the "except type, instance" syntax that came before. Python 3 dropped
support for the latter syntax. Since we no longer support Python 2.4 or
2.5, we have no need to continue supporting the "except type, instance".
This patch mass rewrites the exception syntax to be Python 2.6+ and
Python 3 compatible.
This patch was produced by running `2to3 -f except -w -n .`.
Extension authors (notably at companies using hg) have been
cargo-culting the `testedwith = 'internal'` bit from hg's own
extensions, which then defeats our "file bugs over here" logic in
dispatch. Let's be more aggressive about trying to give extension
authors a hint about what testedwith should say.
This change touches every module in which repository.opener was being used, and
changes it for the equivalent repository.vfs. This is meant to make it easier
to split the repository.vfs into several separate vfs.
It should now be possible to remove localrepo.opener.
Before this patch, "contrib/check-code.py" can't detect these
problems, because the regexp pattern to detect "% inside _()" doesn't
suppose the case that format string consists of multiple string
components concatenated implicitly or explicitly,
This patch does below for that regexp pattern to detect "% inside _()"
problems in such case.
- put "+" into separator part ("[ \t\n]") for explicit concatenation
("...." + "...." style)
- enclose "component and separator" part by "(?:....)+" for
concatenation itself ("...." "...." or "...." + "....")
Some extensions set configuration settings that showed up in 'hg showconfig
--debug' with 'none' as source. That was confusing.
Instead, they will now tell which extension they come from.
This change tries to be consistent and specify a source everywhere - also where
it perhaps is less relevant.
A Mercurial repo signals a file is deleted by raising IOError when the
file's data is requested. This IOError is normally caught by
localrepository.commitctx. With the eol extension enabled and EOL
mappings in place, the eolrepo subclass should ignore IOError because
a deleted file has no line endings to process.
This issue exhibited itself when performing an incremental hg convert
of a revision with deleted files to a repo with an existing .hgeol
file.
Some text editors (Eclipse, for example) do not add trailing newlines,
so diffs often contain annoying "\ No newline at the end of file".
This patch to eol extension simply adds trailing newline on commit.
Before, only the first failure was reported:
abort: b.txt should not have CRLF line endings
while now all of them are listed:
abort: end-of-line check failed:
d.txt in a7040e68714f should not have CRLF line endings
b.txt in fbcf9b1025f5 should not have CRLF line endings
As first suggested by Antoine Pitrou <solipsis@pitrou.net>
The win32text extension does not break eol or vice-versa, so it is not a fatal
error to have both of them enabled. It's just folly. So spewing warnings in
this condition is preferrable to aborting. When both extensions are enabled,
the user now sees:
% hg st
the eol extension is incompatible with the win32text extension
win32text is deprecated: http://mercurial.selenic.com/wiki/Win32TextExtension
M hgext/eol.py
Handle parse errors in the .hgeol similarly to how parse errors in the
.hgtags file are handled: by issuing a warning. This allows the user
to revert the file using 'hg revert' or 'hg update -C'.
