Copy Git's behavior for resuming/aborting a workflow

[mcmire]

When you run this tool for the first time, when it generates a release spec template, if it can't open your editor, it'll just spit out the path to the file it made and quit. Then when you've edited the file, you can just re-run the tool and it'll read the file and resume the workflow.

The problem is that if the tool throws an error while it's executing the release spec, the release spec file will stick around. That's fine, but it means that if you run the tool again, it will attempt to resume the workflow instead of regenerating a fresh release spec. That doesn't always work right now, because some things may have already been applied — some versions of packages might have been updated already, or the release branch may have already been created, or something like that.

Two things: 1) We plan on fixing this issue in #9, and 2) To get around this, we have a --reset option that lets you restart the entire workflow if that's what you want.

But it raises a question: is it expected that re-running the tool will resume the workflow? I'm not so sure. Git, for instance, will produce an error if you attempt to restart a merge or rebase or reapply a cherry-pick while you are resolving conflicts. If you want to start over, you can say --abort; if you want to resume, you can say --continue. This seems like a good workflow, and I think it would make sense to adopt this instead of a --reset option.

[mcmire]

It would be easier to address #17 before addressing this issue. This is because currently it is possible for the tool to crash while executing a release spec, leaving the release branch in a mixed state (changes have been made to some packages, but other changes are outstanding). In such a state, the user could conceivably edit the release spec, then re-run the tool. That would really confuse the tool as now it would be following a different set of instructions on top of the instructions it's already followed, but we would have to account for this possibility while implementing the --continue flag in this PR. Specifically, in the case in which the release spec already exists and --continue is not provided, the tool would have to dissuade people from editing:

Error: It looks like you are in the middle of a run. This could either mean that you haven't edited the release spec yet, or you have and the tool unexpectedly stopped while executing it.

You can re-run this tool with --continue if you want to resume the run, or you can use --abort if you want to revert all changes made so far and start over.

If you need to access the release spec again, here is its path:

... release spec path goes here ...

... stacktrace goes here ...

If we revert all changes after a crash, however, then it places the tool in the same state as if they were to have run it for the first time and failed to edit the release spec. This means that we can recommend that the user (re-)edit the release spec (and frankly I think this is a reasonable request). Using --abort would no longer really be necessary, but we could suggest it anyway for completeness:

Error: It looks like you are in the middle of a run. This means that you haven't edited the release spec yet, or you have and the tool unexpectedly stopped while executing it.

If you need to edit the release spec, please do so now:

... release spec path goes here ...

You can re-run this tool with --continue if you want to execute it again, or you can use --abort if you want to start over.

... stacktrace goes here ...

Therefore I am marking this issue as blocked by #17.

[mcmire]

The branch for this is called copy-git-semantics.