merge: notice uncommited copies (issue1000) As mentioned in msg5349 in issue988, "hg update" doesn't take into account uncommitted copies. To reproduce: ---------------- hg init repo cd repo touch foo hg ci -Am 'add foo' echo >> foo hg ci -m 'change foo' hg up -C 0 hg mv foo bar HGMERGE=false thg --debug -y update -------------------------- A similar problem happens with hg merge --force. I'm attaching a possible patch.

Check for patches repo with os.path.isdir not os.path.exists

hook.py: fix redirections introduced by 323b9c55b328 The only non-obvious part is the use of sys.{__stderr__,__stdout__}, which is needed because sshserver overrides sys.stdout. This makes a test that I added back in revision 7939c71f3132 ineffective.

Issue937: error messages from hooks not sent over HTTP. Turns out that stderr - where ui.warn would send messages - was not being proxied over the HTTP connection. stdout was, and it seems you need both. (The streams are interleaved for readability.) Tested on Ubuntu 7.10 with lighttpd on hgweb.cgi with HTTP Basic auth, no SSL, using a changeset failing win32text.forbidcrlf.

revlog.py: remove extra close() atomictempfile.rename() already calls close().

adjust test-http output to non-default HGPORT, e.g. with run-tests.py -j

hgweb: clarify which address and port can/cannot be bound at startup (bug 769) The error message at startup when the address/port could not be bound was confusing: hg serve abort: cannot start server: Address already in use Be more explicit: $ hg serve -a localhost abort: cannot start server at 'localhost:8000': Address already in use Also be more explicit on success, showing hostname and ip address/port: $ hg -v serve -a localhost -p 80 listening at http://localhost/ (127.0.0.1:80) We are careful to handle a missconfigured machine whose hostname does not resolve, falling back to the address given at the command line. Remove a dead-code error message.

revlog: make sure the files are closed after an exception happens This prevents a corruption when the writes happen after the truncate initiated by the transaction rollback.

merge with crew

make sure not to reuse an existing append-file from a previous failed pull

Fix issue995 (copy --after and symlinks pointing to a directory) I haven't looked at other places that call os.path.isdir to make sure they're OK.

dirstate: ignore mode changes if the fs does not supports the exec bit This can make a difference when e.g. the repo is exported through NFS (which support exec bits) and CIFS (which does not).

merge: require --force when there are deleted files

add a test for a375ffc2aa1b

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.

debugancestor: use repo.lookup when no revlog was specified

update output of test-hgweb

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.

gitweb: show branches in most of the templates

hgweb_mod: add branch helper functions to use in templates

Automated merge with http://hg.intevation.org/mercurial/crew

win32text: use util.binary to detect \0

adjust test-fetch output to non-default HGPORT, e.g. with run-tests.py -j

setup.py: skip inotify if there's no inotify_add_watch Debian Etch doesn't include a sys/inotify.h header, which makes it impossible to compile _inotify.c, making hg uninstallable. The cc.has_function() method is implemented by trying to compile a simple C program. Since there's no redirection involved all error messages are sent to the terminal. This is not particularly pretty but at least it allows the installation to complete.

run-tests.py: add a summary of failed tests at the end

fix incorrect date when committing a tag regression introduced by 989467e8e3a9

merge: fix handling of deleted files

setup.py: os.uname is not available on Windows

Automated merge with http://hg.intevation.org/mercurial/crew

Add inotify extension

convert: rename MAPFILE into REVMAP to disambiguate with filemap

Make mercurial easy installable