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

[John Arbash Meinel]

Aaron Bentley wrote:

> Aaron Bentley wrote:
> | | * 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.
>
> Okay, I've thought about this some more, and I think we can satisfy both
> ~ cases pretty well by using the latest common ancestor as the merge
> BASE, instead of using the working tree.  So:
>
> $ bzr revno
> 43
> $ bzr shelve
> [snpshot S1-960-57 created.]
> $ vi megafile
> [ remove some changes, adjust others, add new changes]
> $ bzr commit
> $ bzr unshelve
> [this will actually do a merge with OTHER=S1-960-57 and BASE=revno 43]
>
> If, after shelving, you make changes to code you changed before
> shelving, then unshelving will produce conflicts, and you'll have to
> sort it out by hand.
>
> Aaron
>
If I am not mistaken, does this mean you are adding the changes into the
revision history, but just as a snapshot/shelf revision? My concern with
that, is that it is not 'nuclear codes' safe in the case of the revfile
format. Because revfiles are append only. Although you probably could
'compact' revfiles, which would use the index file to remove anything
that was not explicitly referenced anywhere. This also makes sense for
the "undo the last commit" fix.

All you really have to do is go through all of the steps for a commit,
but when you are done, you don't add the revision id into the
.bzr/revision-history file. Instead you store it in something like
.bzr/x-shelf, or .bzr/x-snapshot

Is this reasonable, or are you bloating the revision/text store?

I certainly think it would be useful to have a 'bzr compact' command.
Basically lock the branch, iterate through all of the inventories, and
remove all files that are not explicitly referenced.

In the case of hardlinked revfiles, you might have problems, as it might
have been referenced in another tree. But you certainly could make the
statement that "bzr compact" breaks hard-links, and probably could
(optionally) warn about broken hard-links so that you could track down
your special files. (I don't know that you can say what other file
hardlinks to this one, but something like that would be nice.)

So I guess this is 2 threads, bzr shelf is very nice, and could probably
be implemented as a real-life commit (possibly partial commit), with the
final revision id ending up in some alternative file.

Thread 2, bzr compact could clean up all files under .bzr/ such that
unreferenced files are removed. This might be simply bzr branch to a
temp dir, and then replace the original, if abentley's comment about his
bzr branch compacting the tree is true. Though I'm thinking it is more
efficient to just scan for files and fix them one by one.

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20050529/963a0535/attachment.pgp