commands: add example for 'hg add'

extensions: refuse to load extensions if minimum hg version not met As the author of several 3rd party extensions, I frequently see bug reports from users attempting to run my extension with an old version of Mercurial that I no longer support in my extension. Oftentimes, the extension will import just fine. But as soon as we run extsetup(), reposetup(), or get into the guts of a wrapped function, we encounter an exception and abort. Today, Mercurial will print a message about extensions that don't have a "testedwith" declaring explicit compatibility with the current version. The existing mechanism is a good start. But it isn't as robust as I would like. Specifically, Mercurial assumes compatibility by default. This means extension authors must perform compatibility checking in their extsetup() or we wait and see if we encounter an abort at runtime. And, compatibility checking can involve a lot of code and lots of error checking. It's a lot of effort for extension authors. Oftentimes, extension authors know which versions of Mercurial there extension works on and more importantly where it is broken. This patch introduces a magic "minimumhgversion" attribute in extensions. When found, the extension loading mechanism will compare the declared version against the current Mercurial version. If the extension explicitly states we require a newer Mercurial version, a warning is printed and the extension isn't loaded beyond importing the Python module. This causes a graceful failure while alerting the user of the compatibility issue. I would be receptive to the idea of making the failure more fatal. However, care would need to be taken to not criple every hg command. e.g. the user may use `hg config` to fix the hgrc and if we aborted trying to run that, the user would effectively be locked out of `hg`! A potential future improvement to this functionality would be to catch ImportError for the extension/module and parse the source code for "minimumhgversion = 'XXX'" and do similar checking. This way we could give more information about why the extension failed to load.

run-tests: add --slowtimeout and use it for slow tests

serve: unify cmdutil.service() calls of commandserver and hgweb

hgweb: extract factory function of httpservice object The next patch will merge the cmdutil.service() calls of both commandserver and hgweb. Before doing it, this patch wipes out the code specific to hgweb from commands.serve().

hgweb: move httpservice object from commands module This avoids the deep import of hgweb.server at the commands module.

merge: move almost all change/delete conflicts to resolve phase (BC) (API) We have finally laid all the groundwork to make this happen. The only change/delete conflicts that haven't been moved are .hgsubstate conflicts. Those are trickier to deal with and well outside the scope of this series. We add comprehensive testing not just for the initial selections but also for re-resolves and all possible dirstate transitions caused by merge tools. That testing managed to shake out several bugs in the way we were handling dirstate transitions. The other test changes are because we now treat change/delete conflicts as proper merges, and increment the 'merged' counter rather than the 'updated' counter. I believe this is the right approach here. For third-party extensions, if they're interacting with filemerge code they might have to deal with an absentfilectx rather than a regular filectx. Still to come: - add a 'leave unresolved' option to merges - change the default for non-interactive change/delete conflicts to be 'leave unresolved' - add debug output to go alongside debug outputs for binary and symlink file merges

test-merge-changedelete.t: print out debugmergestate We're going to use this to verify the merge state in upcoming patches.

debugmergestate: also recognize change/delete conflicts in the merge state We're going to use this for tests in upcoming patches.

debugmergestate: print out null nodes as 'null' This is so much easier to read than a long string of zeroes, and we're going to have a lot more of these nodes once change/delete conflicts are part of the merge state.

test-merge-force.t: check .orig files separately We're going to soon compare the output of all the non-orig files before and after a resolve, and this makes that more convenient. The .orig files are obviously going to differ between the two.

merge.recordupdates: mark 'a' files as added unconditionally See the previous patch for why we do this.

merge: add a new action type representing files to add/mark as modified This is somewhat different from the currently existing 'a' action, for the following case: - dirty working copy, with file 'fa' added and 'fm' modified - hg merge --force with a rev that neither has 'fa' nor 'fm' - for the change/delete conflicts we pick 'changed' for both 'fa' and 'fm'. In this case 'branchmerge' is true, but we need to distinguish between 'fa', which should ultimately be marked added, and 'fm', which should be marked modified. Our current strategy is to just not touch the dirstate at all. That works for now, but won't work once we move change/delete conflicts to the resolve phase. In that case we may perform repeated re-resolves, some of which might mark the file removed or remove the file from the dirstate. We'll need to re-add the file to the dirstate, and we need to be able to figure out whether we mark the file added or modified. That is what the new 'am' action lets us do.

mergestate: add a cached property accessor for the local context This is going to be useful in an upcoming patch. We make this a public accessor because this is also going to be useful for custom merge drivers.

mergestate: raise exception if otherctx is accessed but _other isn't set We don't want to inadvertently return the workingctx (self._repo[None]).

pager: improve help for --pager= try to clarify how to enable/disable the pager

setup: remove unused py_modules argument to setup() It is never populated and is useless clutter.

test-merge-changedelete.t: add resolve --list output We're going to move change/delete conflicts to the resolve phase, and the resolve --list output is one of the things that will be important to test.

test-merge-changedelete.t: add a file with regular merge conflicts In upcoming patches we're going to move change/delete conflicts to the resolve phase -- it will be important to see how regular conflicts interact with change/delete ones.

filemerge: in ':prompt', use ':fail' tool rather than returning directly The ':fail' tool now knows to write out the changed side for change/delete conflicts. This has no impact right now but will make things better when we move change/delete conflicts in here.

filemerge: in ':fail' tool, write out other side if local side is deleted We do this because we don't want to modify the dirstate for failures, and don't just want to leave the file missing from disk. Plus it's more useful for the user if the changed side is written out -- it is easier to delete a file than to get it back via hg revert.

mergestate: explicitly forget 'dc' conflicts where the deleted side is picked Once we move change/delete conflicts into the resolve phase, a 'dc' file might first be resolved by picking the other side, then later be resolved by picking the local side. For this transition we want to make sure that the file goes back to not being in the dirstate. This has no impact on conflicts during the initial merge.

merge.applyupdates: add all actions returned from merge state At the moment this is a no-op (the only actions defined are 'r', 'a' and 'g'), but soon we're going to add other sorts of actions to the dictionary returned from mergestate.actions().

identify: refer to log to be able to view full hashes