Towards a Shelving MVP

It seems Shelving in the current form is working out quite nicely. I'm
thinking about what more we need so that any of us or our friends would
be comfortable testing it on non-trivial data and calling the feature
set a "minimum viable product". I thought of:

Hardening before being safe to use:

  * Help text should contain a short introduction to how to use; set the
user's expectations; state the limitations (see "Extensions / Not
Supported Initially" section [1] in design doc.).

  * Output should be verbose and clear about what is happening.

  * The prototype should not delete patch files when unshelving, in case
it goes wrong; instead rename/move them.

  * Must handle unsupported scenarios gracefully (e.g. kinds of changes
that we can't yet save and restore in a patch file).

  * If applying a patch fails in any way, or produces conflicts, it
should notify the user and keep the patch (moved somewhere is OK).

  * When 'unshelve' would touch an already modified file, consider
aborting instead of patching. Maybe only patch it if '--force' given.

Some easy UI improvements for a better first impression:

  * Let 'unshelve' choose the most recent shelved patch by default (like
'git stash pop' does).

  * Let 'shelve' default to 'this working directory' and an automatic
name, so that command-line arguments are not required.

  * Tidy up the '--list' output. e.g. show age as minutes/hours/days;
remove file size in bytes.

There remain many limitations listed in [1], mainly of svn diff/patch,
which we will certainly need to address, but I don't think any of them
are essential for the MVP stage. And we have today been talking about
extending the shelving UI to facilitate simple checkpointing, but that
isn't within MVP scope either.

Any thoughts please?

- Julian

[1]
https://docs.google.com/document/d/1PVgw0BdPF7v67oxIK7B_Yjmr3p28ojabP5N1PfZTsHk/edit#heading=h.ysnjkpcjx9ee
Received on 2017-08-25 18:23:12 CEST