changegroup: do not count closed new heads (issue2697) If a closed head gets pulled, we currently see (example): $ hg pull pulling from $TESTTMP/repo2 searching for changes adding changesets adding manifests adding file changes added 2 changesets with 1 changes to 1 files (+1 heads) (run 'hg heads' to see heads, 'hg merge' to merge) A subsequent 'hg heads' doesn't show that head because it is closed. This patch improves the UI response texts for that same use case to: $ hg pull pulling from $TESTTMP/repo2 searching for changes adding changesets adding manifests adding file changes added 2 changesets with 1 changes to 1 files (run 'hg update' to get a working copy) That is, the part "(+1 heads)" is not shown in that case any longer.

merge with crew

shrink-revlog: defend against null first parents

test-contrib: add a test for shrink-revlog We only verify the extension runs and that verify passes at the end as constructing a test repository that would result in a shrink would be nontrivial.

test-simplemerge-cmd.t: move all tests into test-contrib.t

Move test-dumprevlog to test-contrib in anticipation of more contrib tests

shrink-revlog: use a bundler object (see d69c9510d648)

shrink-revlog: update util.opener to scmutil.opener after d13913355390

shrink-revlog: remove \ from docstring

bookmarks: be more restrictive in our Exception catching

strip: make it clear that --force discards changes (issue310)

subrepo: tell Subversion when we are non-interactive (issue2759) $ hg clone repo repo-clone -v updating to branch default resolving manifests getting .hgsub getting .hgsubstate abort: svn: OPTIONS of 'https://subversion.srv/project': Server certificate verification failed: issuer is not trusted (https://subversion.srv)

merge with stable

tests: check for (*/sec) instead of (*B/sec) to match (X bytes/sec) I just had: transferred 606 bytes in 2.9 seconds (211 bytes/sec)

test-repair-strip: turn into new style test

extdiff: fix broken symlinks handling (issue1909)

tags: catch more corruption during cache parsing (issue2779)

run-tests: do chdir for tests under a lock for thread safety

run-tests: add iolock to vlog

patch: remove redundant variable in iterhunks()

merge with stable

merge default heads

commit: improve --date help text

merge with stable

test-transplant: fix missing file addition

tests: add script to disable a selected wire protocol capability This can be used to test that the client and server both fall back to the previous wire protocol when the capability is not supported. It is currently used by test-push-http.t and I plan to use it for the HTTP long argument support tests.

mq: prevent traceback when qfinish patches not in series. When mq status entry referencing a patches that is not in series `hg qfinish -a` used to issue a traceback. This states is inconsistent but might happen regularly when people misuse hg up -mq. This changeset prevent hg from crashing. The faulty entry is finished anyway and a warning is issued.

check-code: separate warnings to avoid repetitive str.startswith

atomictempfile: rewrite docstring to clarify rename() vs. close().

atomictempfile: avoid infinite recursion in __del__(). The problem is that a programmer using atomictempfile directly can make an innocent everyday mistake -- not enough args to the constructor -- which escalates badly. You would expect a simple TypeError crash in that case, but you actually get an infinite recursion that is surprisingly difficult to kill: it happens between __del__() and __getattr__(), and Python does not handle infinite recursion from __del__() well. The fix is to not implement __getattr__(), but instead assign instance attributes for the methods we wish to delegate to the builtin file type: write() and fileno(). I've audited mercurial.* and hgext.* and found no users of atomictempfile using methods other than write() and rename(). I audited third-party extensions and found one (snap) passing an atomictempfile to util.fstat(), so I also threw in fileno(). The last time I submitted a similar patch, Matt proposed that we make atomictempfile a subclass of file instead of wrapping it. Rejected on grounds of unnecessary complexity: for one thing, it would make the Windows implementation of posixfile quite a bit more complex. It would have to become a subclass of file rather than a simple function -- but since it's written in C, this is non-obvious and non-trivial. Furthermore, there's nothing wrong with wrapping objects and delegating methods: it's a well-established pattern that works just fine in many cases. Subclassing is not the answer to all of life's problems.