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

[Aaron Bentley]

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

John A Meinel wrote:
| Aaron Bentley wrote:
|>You could also just wipe the portions that contained the nuclear launch
|>codes and remove the launch codes from the indices.
|>
|
|
| This is probably actually the easiest thing to do. With something like a
|  'nuke-selected-revision-id' or something similar which would destroy a
| specific section. The only problem is if they were added and the indexes
| not updated yet, or something like that, so they are secretly in there,
| without knowing about it. Hence 'bzr compact' to remove everything that
| isn't referenced.

So there are two forms of compaction: removing everything from the
revfile indices that isn't referenced in a revision, and removing
everything from the revfile text that isn't referenced in the revfile index.

| Actually, if you were super
| special, you might notice in a later unshelf that the changes already
| exist, and just reference them.

| I don't know if the internal code would care...

| The bigger difficulty would
| be figuring out that the current commit matches a previous entry in the
| revfile.

Well, hashes are easy to get at, so you can get a list of probable
matches easily, and then confirm whether the probable match actually is
a match.  This operation scales with the size of the store, but there
are probably ways of trimming it down.

|>- From what I understand, revfiles are already updated in a hard-link-safe
|>way.
|
|
| Actually, earlier discussions indicated that a revfile can be updated in
| place. Since having unknown contents is fine. Because you use the index
| to find everything. And having indexes updated in place is also fine,
| since you truly only use the revision history to index what you need.
| Other than locking issues, it seems like you could have all of your
| revisions in one giant pool, and revfiles would still work.

Yes, and this is also true of the current git-like storage.  Having
central stores would speed up "pull"s and "branch"es nicely, because
you'd be able to avoid downloading any text, inventory or revision that
you already had.

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

| Is the only way to do this to stat() all files in a given filesystem,
| and look for ones with the same inode numbers?

AFAIK, yes.  Which makes it theoretically impossible, since you may not
have access to the whole filesystem, but usually, it will be possible.
However, you can easily determine which files have more than one link.

|>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.
|>
|
|
| Well, it also depends how you handle revfiles in the future. When you
| branch from remote, you will have to know the revfile and revindex
| names. So you *could* just copy the complete files across. Or you could
| recreate the revfile and revindex based on the revision history and
| inventory.

Yes, the copy operation is a memeber of the Store class, so you can have
special optimizations when both stores are of the same type.  I think it
would be nice to just grab the interesting portions of the revfile, though.

| I think it would be nice to have a command to get the cruft out of your
| revision store.

Currently, it's very hard to get cruft *into* your revision store, so
I'd tend to wait until there was a clear demand.  But hey, if you want
to, don't let me stop you.

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

iD8DBQFCnIrt0F+nu1YWqI0RAm6GAJ91xnolrnPHACLN0sKUvcLbFfXMowCfQAlx
+5PXkUkdq8mOAdetaTesr/k=
=WvtP
-----END PGP SIGNATURE-----