(fwd) bzr shelve feedback

[Jan Hudec]

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

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.

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

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

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

-- 
						 Jan 'Bulb' Hudec <bulb at ucw.cz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051124/c18c5743/attachment.pgp