localrepo.commit: normalize commit message even for rawcommit.
This normalization consists of:
- stripping trailing whitespace
- always using "\n" as the line separator
I think the main reason rawcommit was skipping this normalization was
an attempt to preserve hashes during an hg->hg conversion.
While this is a nice goal, it's not particularly interesting in
practice. Since SHA-1 is so strong, the only safe way to do it is to
have absolutely identical revisions. But:
- if the original revision was created with a recent version of hg,
the commit message will be the same, with or without that
normalization
- if it was created with an ancient version of hg that didn't do any
normalization, even if the commit message is identical, the file list
in the changelog is likely to be different (e.g. no removed files),
and there were some old issues with e.g. extra file merging, which
will end up changing the hash anyway
- in any case, if one *really* has to preserve hashes, it's easier
(and faster) to fake a partial conversion using something like:
hg clone -U -r rev orig-repo new-repo
hg -R new-repo log --template '#node# #node#\n' > new-repo/.hg/shamap
Additionally, we've had some reports of problems arising from this lack
of normalization - e.g.
issue871, and a user that was wondering why
hg export/hg import was not preserving hashes when there was nothing
unusual going on (it was just import doing the normalization that had
been skipped).
This also means that it's even more unlikely to get identical revisions
when going $VCS->hg->$VCS.
setup.py: use a simplified custom version of CCompiler.has_function
The original one doesn't remove its temporary files and even creates
a temporary file in the CWD.
adjust test-fetch output to non-default HGPORT, e.g. with run-tests.py -j