(fwd) bzr shelve feedback

[Jan Hudec]

On Thu, Nov 24, 2005 at 16:01:58 -0500, Aaron Bentley wrote:
> -----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.

I don't have it thought out perfectly yet. But basically it would take
the stack of shelves based on revision A and create a new stack of
patches on revision B and mark them as a 'new version' of that stack.

> The merge performed by unshelve would probably be
> THIS = .
> BASE = shelf-basis
> OTHER = shelf

... or the weave-merge... when using the shelf like quilt, you'd
probably not have changes that are neither shelved nor commited.

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

I'd rather store them in the weave, not because of space savings, but
mainly for ease of merging and simplicity. On the other hand when it's
used in the quilt way, you could quickly gather rather many shelf
revisions (because they are never deleted) and most of them is really
worthless once the feature is ready. Thus I'd prefer if fetch could not
bring them over unless explicitly asked for (and push/pull would not ask
by default).

Well, perhaps they could be separate storage though somehow - but I'd
expect that to be actually harder to implement well.

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

Actually not. I would rather create new revisions and mark them as new
version of the shelf.

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

I'll have to look at them. Because finding the current shelves must be
fast. So I'm likely to end up with some index or something.

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

I'd rather go with the same repository. Neither stgit nor mq seem to do
it that way, but I really like the conceptual simplicity of it.

I have started writing a vim client to version control tools some time
ago. So I'll first finish the features with mercurial there and then
start looking at bzr.

--
						 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/20051125/ddca3128/attachment.pgp