[PATCH v2] shelve: add a shelve extension to save/restore working changes

[Matt Mackall]

On Mon, 2013-06-03 at 17:06 -0700, Bryan O'Sullivan wrote:
> # HG changeset patch
> # User Bryan O'Sullivan <bryano at fb.com>
> # Date 1370304398 25200
> #      Mon Jun 03 17:06:38 2013 -0700
> # Node ID 3bad6a49d773847e8ac42448ba40140aa86eafa6
> # Parent  11fce4dc68f060e96cc06cc88da72e2c9da1022b
> shelve: add a shelve extension to save/restore working changes

Ok, I've been kicking the tires on this a bit. Some initial reactions:

a) needs to work with mq patches applied
b) fails three tests
c) the os.path module is dead to us, use a VFS for path manipulation
   (http://mercurial.selenic.com/wiki/WindowsUTF8Plan)
d) the default shelve listings are a bit confusing:
@-01            [3 seconds ago]   shelved from @ (9a8c25f3): shelve: add a sh...
@               [4 hours ago]     shelved from @ (9a8c25f3): shelve: add a sh...

Is there precedent for this format? The "shelved from @ (9a8c25f3):"
wastes valuable columns. We seem to have bookmark/branch on the left,
perhaps we should just have a "base" column. We also tend to prefer "()"
to "[]". We could perhaps shorten the timestamps to '3s', '4h', '2d' as
well.

e) shelve/unshelve/shelve -l
   - doesn't match the pattern of tag/tag --remove/tags, book/book
-d¹/books, branch/ugh²/branches
   - doesn't match git's stash/stash pop/stash list either
   - sorta matches qpush/qpop
   - if we want to make a UI choice here, this is the last opportunity
f) it always drives me a little crazy guessing which of zip/unzip has
the -l flag.. and this disagrees.
g) do we want to accept a list of files?

1. Ugh, that was stupid of us.
2. Yeah, well..
-- 
Mathematics is the supreme nostalgia of our time.