merge with stable
merge with stable
splicemap: move parsesplicemap to convcmd.py (issue2084)

parsesplicemap is only referenced from convcmd.py
This move is necessary to enable other changes related to
this issue
splicemap: improve error handling when source is hg (issue2084)

1. Introduced 2 levels of error handling for splicemap files
   a. Check the splicemap file for rules which are same across different
      types of source repos.  This is done through enhancing parsesplicemap
      function
   b. Check revision string formats.  Each repo may have their own format.
      This is done usign checkrevformat function
   c. Implemented the above two for hg
splicemap: improve error handling when source is git (issue2084)

Implemented similar error handling that is done for hg in an earlier revision.
These are:
   a. add checking for splicemap file format
   b. add checking for each revision string formats
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.
check-code: add more path sep glob checks
test-nested-repo.t: touch another file inside nested repo

This helped uncover a bug in a patchset I've been writing.
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.

--HG--
extra : rebase_source : d89e2a6c486fe2326f714438b99a8a8e4bd12328
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.

--HG--
rename : mercurial/templates/map-cmdline.default => mercurial/templates/map-cmdline.phases
extra : rebase_source : 5839ecc0bcab5ab027aa3d627cfa8bd86b0d56c7
templater: fix output instability from gsoc patches

--HG--
extra : rebase_source : 7dee96c5d96ac5723ad34e422a3b02a745ef321f
merge with stable
tests: fix test-commandserver phase . output for windows
tests: check path separator in moves
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.

--HG--
extra : rebase_source : b4221cb3b6d2e479d45e779d2b73bf47b0623d02
merge with stable
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).
dirstate.walk: call match.explicitdir or traversedir as appropriate
localrepo.commit: hook into match.explicitdir
purge: hook into match.explicitdir and traversedir