Anton Shestakov <av6@dwimlabs.net> [Thu, 25 Apr 2019 17:19:41 +0800] rev 4604
evolve: mention that not all successful operations currently update wdir
Martin von Zweigbergk <martinvonz@google.com> [Tue, 23 Apr 2019 11:07:28 -0700] rev 4603
evolve: add progress support for --continue
The progress starts where it left off when the previous command ran
into merge conflicts.
Martin von Zweigbergk <martinvonz@google.com> [Tue, 23 Apr 2019 10:56:42 -0700] rev 4602
evolve: reduce scope of progress-related variables
Martin von Zweigbergk <martinvonz@google.com> [Tue, 23 Apr 2019 10:49:47 -0700] rev 4601
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.
Martin von Zweigbergk <martinvonz@google.com> [Tue, 23 Apr 2019 10:52:33 -0700] rev 4600
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.
Martin von Zweigbergk <martinvonz@google.com> [Tue, 23 Apr 2019 09:45:45 -0700] rev 4599
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.
Martin von Zweigbergk <martinvonz@google.com> [Tue, 23 Apr 2019 09:35:34 -0700] rev 4598
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).
Martin von Zweigbergk <martinvonz@google.com> [Tue, 23 Apr 2019 09:31:32 -0700] rev 4597
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.
Martin von Zweigbergk <martinvonz@google.com> [Tue, 23 Apr 2019 10:20:03 -0700] rev 4596
tests: add some basic testing of progress
Martin von Zweigbergk <martinvonz@google.com> [Fri, 19 Apr 2019 10:03:39 -0700] rev 4595
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.
Martin von Zweigbergk <martinvonz@google.com> [Fri, 19 Apr 2019 11:02:35 -0700] rev 4594
evolve: use util.acceptintervention() for closing transactions
util.acceptintervention() will close the transaction on
InterventionRequired.
Martin von Zweigbergk <martinvonz@google.com> [Fri, 19 Apr 2019 10:32:32 -0700] rev 4593
evolve: use context manager for transactions
Martin von Zweigbergk <martinvonz@google.com> [Fri, 19 Apr 2019 10:52:16 -0700] rev 4592
evolve: use consistent message and just re-raise InterventionRequired
Martin von Zweigbergk <martinvonz@google.com> [Fri, 19 Apr 2019 10:47:12 -0700] rev 4591
evolve: use standard InterventionRequired instead of MergeFailure
Martin von Zweigbergk <martinvonz@google.com> [Fri, 19 Apr 2019 10:41:56 -0700] rev 4590
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.