match: introduce explicitdir and traversedir match.dir is currently called in two different places: (1) noting when a directory specified explicitly is visited. (2) noting when a directory is visited during a recursive walk. purge cares about both, but commit only cares about the first. Upcoming patches will split the two cases into two different callbacks. Why bother? Consider a hypothetical extension that can provide more efficient walk results, via e.g. watching the filesystem. That extension will need to fall back to a full recursive walk if a callback is set for (2), but not if a callback is only set for (1).

merge with stable

run-tests: when running in parallel, delete tmpdirs immediately This is especially important if extensions that use inotify are enabled, because it's very easy to hit the inotify max_user_instances limit without this.

tests: check path separator in moves

tests: fix test-commandserver phase . output for windows

hfs+: rewrite percent-escaper (issue3918) The original code was a bit too clever and got confused by some cp949 Korean text. This rewrite bytes the bullet and manually decodes UTF-8 sequences. Adds some doctests.

merge with stable

revert: ensure that copies and renames are honored (issue3920) Previously, we restored the states of files, but not the additional information the dirstate uses to track copies and renames.

hgignore: fix regression with hgignore directory matches (issue3921) If a directory matched a regex in hgignore but the files inside the directory did not match the regex, they would appear as deleted in hg status. This change fixes them to appear normally in hg status. Removing the ignore(nf) conditional here is ok because it just means we might stat more files than we had before. My testing on a large repo shows this causes no performance regression since the only additional files being stat'd are the ones that are missing (i.e. status=!), which are generally rare.

templater: fix output instability from gsoc patches

log-style: add a log style that is default+phase (issue3436) There is a new style called phases style. Usage:: hg log --style phases Why do we need this new style - in what way is it different from or similar to existing styles? The new style is default + phases information. With the new phases feature the users exhibited their desire for a new style that could help them. Why do this need a new style - couldn't it be folded into an existing style? The default style and the new one are about the same, the difference is the phases tag. The users find both styles useful, this means that the both styles must exist.

templater: show the style list when I try to use a wrong one When someone try to use a wrong style, a list with sugestions will appear. In the test-log.t file it's a test that prove this thing.

test-nested-repo.t: touch another file inside nested repo This helped uncover a bug in a patchset I've been writing.

check-code: add more path sep glob checks

splicemap: improve error handling when source is subversion (issue2084) Implemented error handling on splicemap file when source is subversion (This checks are similar to when source is hg or git). The revision string is expected to be of svn:<uuid><path>@<number> format. the test case has been enhanced to check this format.