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

[Bryan O'Sullivan]

On Tue, Jun 11, 2013 at 4:41 PM, Matt Mackall <mpm at selenic.com> wrote:

>
> a) needs to work with mq patches applied
>

I've tried to address that today, but it's heavy going.

The obvious thing to do is temporarily save repo.mq.applied, empty it
before committing (to defeat mq's commit-on-patches check), then restore
it. But this doesn't work, for mysterious reasons.

Here's what I think I see so far: Pierre-Yves's repoview code seems to be
implicated in making the mqrepo's mq object get deleted and recreated on
every access, so setting repo.mq.applied works and then the repo.mq object
is deleted and recreated immediately. There's enough magic in the call
stack that I really haven't figured out what is going on yet, though, so
please don't take this as anything more than me scratching my head out loud.


> b) fails three tests
>

Works On My Machine (TM).


> c) the os.path module is dead to us, use a VFS for path manipulation
>    (http://mercurial.selenic.com/wiki/WindowsUTF8Plan)
>

Will do.


> 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?


Sort of (it's vaguely similar to "git stash list", but more informative),
but I'm happy to discuss the format.


> The "shelved from @ (9a8c25f3):"
> wastes valuable columns.


I could drop 'shelved from ', but I think the remainder is actually of
value.


> We seem to have bookmark/branch on the left,
> perhaps we should just have a "base" column.


The name on the left is user-settable at the time of shelving - it's
bookmark or branch if no name is given, but you can specify a more helpful
mnemonic name if you prefer.

We also tend to prefer "()"
> to "[]". We could perhaps shorten the timestamps to '3s', '4h', '2d' as
> well.
>

Sure, that makes sense.


> 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
>

I don't have a particular pattern in mind to follow - which would you
prefer to see?


> g) do we want to accept a list of files?
>

Yes (and we already do). In fact, if the record extension gets an overhaul
that makes it more robust, and we figure out how to do cross-extension
calls (surprisingly hard right now), I may eventually integrate support for
that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20130612/bf1f6a19/attachment.html>