[Extension] Dirty hack of 'shelve' and 'unshelve' command

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Ellerman wrote:

| * I don't see why you can't let the user edit a hunk (Aaron), and then
| recalculate the context and offsets. It's just a matter of getting the UI
| right. I think.

I think the 'right ui' varies.  While you might like that, I'd rather
pull the file up in gvimdiff or meld.  So let's support as many styles
as we can without undue contortions.

| * I don't think I understand you (Aaron) when you say "'unshelve' will
restore
| the tree to the state it was in when you issued the 'shelve' command" -
| because I *don't* want it to do that. I want to shelve some stuff,
maybe edit
| something, commit, make more changes .. blah, then unshelve and keep
working.
|
| I also don't want commit to unshelve, because then I might commit, make
| another unrelated change, commit => ouch I just commited my shelved patch
| without realising!

To me, this looks like a nice workflow:
# Make 3 logically distinct changes
$ gvim mega-file
$ bzr shelve
$ meld mega-file ~/mega-file.old
$ bzr commit
* Unshelved previous changes
$ bzr shelve --all
$ gvimdiff mega-file ~/mega-file.old
$ bzr commit
* Unshelved previous changes
$ bzr commit

So we seem to want different things; I want unshelve to be a really
flexible way to separate the logically distinct changes, and I don't
want unshelve to produce conflicts.  You want the freedom to introduce
new changes.  I'm not sure these desires are compatible.

Oh, and bad commits aren't the kind of pain they are in Arch.  You can
just remove the last line of the revision history.

More likely what happens is
$ bzr shelve
$ bzr commit
* Unshelved previous changes
$ gvim mega-file
$ bzr diff
# Ugh! I mixed two logically distinct sets of changes-- the
previously-shelved changes, and some new stuff.
$ bzr shelve
...

So shelve can be the solution in that case, too.

| * As to a "proper" implementation of shelve (Aaron), I think I agree your
| option d) sounds the most promising. I haven't really worried about it
yet
| though, I just wanted to explore how the user experience would be.

Okay, I think that works whether you're supposed to introduce new
changes or not.  It just changes the timing of the snapshot.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCleoM0F+nu1YWqI0RAjVhAKCGTJ+Gb/SLP80M7gB21nNE+BqbDgCfcQIX
hqvXbrI3qwt+CjSP7nTqNvw=
=mdC1
-----END PGP SIGNATURE-----