evolve: delete dead calculation of number of troubled revisions The "count" variable is recalculated in the regular (no --continue) code path and it isn't used anywhere else (it used to be set to 1 in the --continue code path, but that now has its own progress counting).

evolve: drop nested locks and transactions All callers of _solveone() now take the locks and start the transactions, so there's no need to do that anymore.

next: start transaction before calling _solveone() All other callers do this, and I'm about to make _solveone() not create a transaction.

evolve: use single transaction also when continuing

evolve: run in a single transaction This speeds up `hg evolve --all` of a stack of 24 commits in the hg repo from 11.5s to 3.7s (3x). As can be seen in the tests, it also avoid some warnings about transiently unstable commits.

evolve: extract function for solving one revision, including merges Will make the next patch simpler.

evolve: mention that --all is the default behavior now

evolve: mention that not all successful operations currently update wdir

evolve: add progress support for --continue The progress starts where it left off when the previous command ran into merge conflicts.

evolve: reduce scope of progress-related variables

evolve: move progress-clearing out of _cleanup() The progress is only used with --all or --rev, so there's no need to clean it in any other case. It's therefore easier to clean it specifically in that case.

evolve: stop passing no-op "progresscb" into continueevolve() The "progresscb" doesn't do anything in the --continue case, so there's no need to pass it into continueevolve(). This lets us remove the --no-all that was added to the test as a workaround.

evolve: _solveunstable() update progress only once There's no need to draw it, then possibly write text over it (with --verbose), and then draw it again.

evolve: don't update progress just before clearing it _cleanup() will clear the progress, so there's little reason to update it just before (except for progress.debug=yes).

evolve: clean up progress bar also when using -r It looks like 1fe3da0b4601 (evolve: add --rev option to the evolve command, 2015-05-05) forgot to update the "showprogress" variable.

tests: add some basic testing of progress

evolve: increment progress *after* a whole merge commit is done The "re-stabilize" step was using the progress that was supposed to be for the next revision.

evolve: use util.acceptintervention() for closing transactions util.acceptintervention() will close the transaction on InterventionRequired.

evolve: use context manager for transactions

evolve: use consistent message and just re-raise InterventionRequired

evolve: use standard InterventionRequired instead of MergeFailure

evolve: don't use exception for local flow control The LocalMergeFailure class was added in 3f91654713dd (obsolete Move merge failure handling into stabilize code, 2012-08-20). I think the "if compat.hasconflict(r)" check was added later. Now that we have that check, we should use that for flow control instead. Note that this means that any unexpected exception from _relocatecommit() will now just raise (and roll back the transaction). I think that's an improvement.

evolve: reduce indentation with an early return statement

evolve: remove a useless return statement at end of function

test: move a test to an appropriate test file This patch introduce a new test file test-evolve-orphan-corner-cases.t for tests which covers corner cases.

test: improve the title of a test

test: remove duplicated test We have the test in test-evolve-orphan-split.t which is covering the same case this test does. Also this test states that evolve shows some error in split case, but now this is not the case we update to the top of splitted csets.

evolve: warn user for the metadata being lost in public divergence resolution This patch print warnings if some "extras" of a divergent changeset that is possibly important metadata which is being lost during the resolution of public divergence.

evolve: show a status message when merging leads to public cset I think it would be fine to tell the user that merging the two divergent csets while resolving public divergence resulted into the public cset itself. If you think we don't need to tell the user, then we can include this in debug-mode for debugging purposes at least.

test: use a shorter test name This is still long but easier to read.