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

[Aaron Bentley]

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

John Arbash Meinel wrote:

> If I am not mistaken, does this mean you are adding the changes into the
> revision history, but just as a snapshot/shelf revision?

I'd say "adding the changes into the revision stores", rather than
"revision history", but yes, this was one thing I proposed.

> My concern with
> that, is that it is not 'nuclear codes' safe in the case of the revfile
> format.

So some other options I suggested included using temp stores for
unique-to-snapshot items, and just using plain full-tree copies.

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

You could also just wipe the portions that contained the nuclear launch
codes and remove the launch codes from the indices.

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

Unless you change the file storage, you'll still bloat the stores.  But
I'm not sure whether the amount of bloat would be significant.

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

- From what I understand, revfiles are already updated in a hard-link-safe
way.

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

Yes, if you've got nuclear launch codes, you'll want to get rid of all
copies.

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

One of the limitations of remote file access is that you can't list what
items are present in a store.  So I can only copy items that are
referenced in the revision history or inventory of a revision.

> Though I'm thinking it is more
> efficient to just scan for files and fix them one by one.

Yes, delete is usually faster than copy.  It's just a bit trickier that
way, but no biggie.

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

iD8DBQFCm/vb0F+nu1YWqI0RAp9kAJ910fpVqvUDWhISKONRSQaAhNWwowCcD3ex
8mg3xcw4pdlHsS6+fnAxrEg=
=z8Vd
-----END PGP SIGNATURE-----