(fwd) bzr shelve feedback

[Aaron Bentley]

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

Jan Hudec wrote:
> On Thu, Nov 24, 2005 at 13:54:57 -0500, Aaron Bentley wrote:
> 
>>>I suppose the best way to do this is to store the diff with the
>>>last-commited revision (let's call it A) in a changeset (for revert),
>>>and to do a 3-way merge (working copy, A, A+changeset) (for unrevert).
>>
>>Actually, Robert has pointed out that we don't actually need changesets
>>to do this, just a way to store tree snapshots.
> 
> 
> Could they be stored as revisions?

Certainly.

> I think shelving can be thought of as
> checking in the hunks to shelve and switching back to previous head and
> unshelving switching back to the shelved revision. Doing shelve, commit,
> unshelve would mean to merge the revisions, which should easy as the code is
> already there. Then there could be a 'reshelve', ie. qrefresh equivalent,
> that would commit the merge.

I'm not clear what reshelve does, but the rest is certainly possible.
The merge performed by unshelve would probably be
THIS = .
BASE = shelf-basis
OTHER = shelf

> These special shelve would be invisible to push, pull and fetch by default
> (could be made visible by an option) and pull/push would be (for start)
> forbidden when shelve revision is current on the target.

Implementation of hiding may be a problem.  If you mean to store them
separately, you lose a lot of the compression advantages of weaves.
Making some revisions in a weave hidden would be hard.

> Support could then be added to insert new commits in between other revisions
> and removing them again -- to split and join patches.

I'm not sure what you mean here.  You're thinking of rewriting
revisions, are you?

> A 'shelve' revision would in addition to normal revision have a pointer to
> a 'previous version' of that revision, so the shelve itself would be
> versioned (at least mq versions the queue).

Hmm, could be.  I guess you'd want to use the parent ids to represent
the pending-merges at shelve time.  Anyhow, that's easy with revision
properties.

> ... ok, I believe I will have it if I write it, right? Could someone estimate
> and tell me how much hacking the core bzr it would take (and what can be done
> in a plugin)?

Without setting up a separate repository for shelf revisions, I think
the only core change would be to create a way to commit without altering
the revision history.  With a separate repository, I'd say it's a
medium-sized task.

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

iD8DBQFDhipG0F+nu1YWqI0RAgz8AJ0UjLQwKQF3O8lEoQ3ykmnVZGiu/gCcChH2
0pBJNhesNFZ5EC4uZQ+yYKA=
=u9XW
-----END PGP SIGNATURE-----