merge: handle subrepo merges and .hgsubstate specially In an upcoming patch, we will update .hgsubstate in a non-interactive worker process. Merges of subrepo contents will still need to occur in the master process (since they may be interactive), so we move that code into a place where it will always run in what will become the master process.

tests: update test output (will be folded into parent)

merge: split out mostly-non-interactive working dir updates In a later patch, we'll run these updates in parallel.

extensions: obsolete and remove interhg extension With the addition of the websub filter extension this extension is no longer needed. We maintain a sort of backwards compatibility by reading the [interhg] section and using it as we would use the [websub] section.

hgweb: apply the websub filter to revision descriptions In order to use this, add a [websub] section to your configuration and add websub expressions such as: italic = s/\b_(\S+)_\b/<i>\1<\/i>/ bold = s/\*\b(\S+)\b\*/<b>\1<\/b>/ issues = s|issue(\d+)|<a href="http://bts.example.org/issue\1">issue\1</a>|i bugzilla = s!((?:bug|b=|(?=#?\d{4,}))(?:\s*#?)(\d+))!<a href="http://bz.selenic.com/\2">\1</a>!i This also adds documentation (proofed by Kevin!) to the config help section.

hgweb: add websub template filter The purpose of this new filter is to make it possible to partially replace the functionality of the interhg extension. The idea is to be able to define regular expression based substitutions on a new "websub" config section. hgweb will then be able to apply these substitutions wherever the "websub" filter is used on a template. This first revision just adds the code necessary to load the websub expressions and adds the websub filter, but it does not add any calls to the websub filter itself on any of the templates. That will be done on the following revisions.

addremove: don't audit the path for paths already in the dirstate Now that dirstate.walk returns None for paths under symlink directories, addremove doesn't need to validate each path it sees to look for files under symlinks. On a large repository this brings addremove from 6.3 seconds down to 3.65 (42%) since addremove no longer has to stat every directory of every file to determine if the file is inside a symlink directory. I put it through our benchmark and see no perf hit to any other commands.