merge: change debug logging - test output changes but no real changes Preparing for action list split-up, making sure the final change don't have any test changes. The patch moves debug statements around without really changing anything. Arguably, it temporarily makes the code worse. The only justification is that it makes it easier to review the test changes ... and in the end the big change will not change test output at all. The changes to test output are due to changes in the ordering of debug output. That is mainly because we now do the debug logging for files when we actually process them. Files are also processed in a slightly different but still correct order. It is now primarily ordered by action type, secondarily by filename. The patch introduces some redundancy. Some of it will be removed again, some of it will in the end help code readability and efficiency. It is possible that we later on could introduce a "process this action list and do some logging and progress reporting and apply this function". The "preserving X for resolve" debug statements will only have single space indentation. It will no longer have a leading single space indented "f: msg -> m" message. Having this message double indented would thus no longer make sense. The bid actions will temporarily be sorted using a custom sort key that happens to match the sort order the simplified code will have in the end.

merge: move constant assignments a bit and use them more

merge: change priority / ordering of merge actions The ordering of actions matters. Normal file system semantics is that files have to be removed before a directory with the same name can be created. Before the first ordering key was to have 'r' and 'f' actions come first, secondary key was the filename. Because of future refactorings we want to consistently have all action types (with a sensible priority) as separate first keys. Grouped by action type, we sort by filename. Not processing in strict filename order could give worse performance, especially on spinning disks. That is however primarily an issue in the cases where "all" actions are of the same kind and will be grouped together anyway.

run-tests: fix --interactive option ``TTest._testpath`` never existed. This must be the remain of some contributors side refactoring.

run-test: fix AttributeError in the --interactive prompt One must choose between ``"y yes".split()`` and ``('y', 'yes')``. I choose the later. The feature still crash when you answer "yes" to use it. But at least, the prompt itself works.

run-test: restore the -i prompt by write .err before checking if it exists The `--interactive` flag workis by overwriting the original test file by its `.err` version. So we need to write it before calling `self.fail`. Otherwise the `.err` file does not exists and `--interactive` is ignored. We can move that block code around because it is dedicated to write changed output and we moves it in the try-except dedicated to handling changed output. Note that the flog is still badly broken after this change. But at least it crash instead of being ignored.

run-tests: move _gethgpath() into TestRunner

run-tests: move string escaping to TTest With this patch, TTest is almost fully self-contained and extractable. Only logging functions remain outside of its class.