Fwd: nuclear lauchcodes and nuclear waste

[John Arbash Meinel]

James Blackwell wrote:
> On Tue, Jan 10, 2006 at 07:32:48AM -0600, John Arbash Meinel wrote:
> 
>>>>But I just posted a [PLUGIN] to the list (which didn't get any hits),
>>>>where I specifically implemented the ability to remove unused revisions
>>>
>>>>from the store.
> 
> 
> James Blackwell:
> 
>>>Should it generally be considered safe or can it have intended, but not
>>>generally predictable, side effects?
>>
>>'bzr clean-branch' will check what revisions you have in the
>>revision-store, and then go through all the weaves and clean out ones
>>that are not present. It does check the ancestry of every revision, so
>>it won't remove parents of revisions you are saving.
> 
> 
> I've got no doubt that its safe on a local perspective. =) I'm wondering
> what sort of ramifications are involved with it comes to merge.
> 
> Imagine: 
>  1. You merge me
>  2. I use clean-branch as part of excising some large logfile creatively
>  named "logfile"
> 
> Now, what happens if:
>  1a. I merge you. Does logfile come back, perhaps?
>    or
>  2b. You merge me again. What do your tree and stores look like?

With our current merge logic, anything that exists in your weave file
gets pulled into my weavefile. So if you had logfile when I merged, I
would get it. If you delete it, when you merge me, you will get it back.

However, you would not get the revisions which created it, and running
'bzr clean-branch' would detect it as unreferenced information.

In the future of knits, we won't pull in unreferenced information. So if
I merge you, I will not get logfile, thus you won't get it back from me.

> 
> 
>>This is safe until we have a shared repository, (though if the
>>revision-store is also shared, then it would still be safe).
> 
> 
> I'd like verify your meaning of "shared repository" means "a repository
> that can be written by multiple people" and not a branch shared by
> multiple peple (which I have just put on BzrGlossary as "shared branch".)
> 
> 

Yes. I'm talking about more than one branch sharing the same
'.bzr/weaves' directory. Hard-linking is not sufficient, since we break
links when we write weaves.

> 
>>'bzr clean-branch --all', is a little more risky, since it grabs the
>>current revision, checks the ancestry of that revision, and removes
>>revisions from the revision store which are not in the ancestry. And
>>then it sanitizes the weaves. So if you merged from someone else, and
>>then decided you didn't want those revisions, you could clean them out.
> 
> 
> So its like a cherry pick of sorts? That sounds really cool. Can you
> provide an example? 

Not exactly cherry pick. Lets look at it this way:

branch Mainline Has lots of commits, merges from people
branch Oops, accidentally commits 'logfile' which is a 4MB beast.

cd $Mainline
bzr merge ../Oops
# At this point the user reviews the changes as says, I don't want that
# file in mainline
bzr revert
# Branch is clean. But the revision data for Oops is still in the tree
# and still exists in the weaves.
bzr clean-branch
# Shouldn't do anything because the Oops revisions are fully installed
bzr clean-branch --all
# Should remove the information pointed to by Oops revisions, since they
# are not in the current revision history.

Mainline alerts Oops to the mistake.
cd $Oops
bzr uncommit
bzr rm logfile
bzr commit -m "Same commit message. (now without Oops)"
bzr clean-branch --all

cd $Mainline
bzr merge ../Oops
bzr commit -m "Now I should not have the Oops revisions."

So one of the most powerful uses of clean-branch --all is when
uncommitting, as it will truly remove the information.

One of the reasons to have the code in bzr core is to bring back 'bzr
uncommit --all' to actually remove the information from the branch.

> 
> 
>>In general, I think the code is safe. It pays attention to ancestry for
>>each weave, and it run 'Weave.check()' after sanitizing each weave,
>>before writing it back to disk. (If you run it, you will notice it says
>>'checking' much more than it says 'cleaning').
>>
>>Honestly, I can see this being part of bzr core. I just knew it was
>>possible to write as a plugin, and that is where I prefer to do new work
>>if it is possible to do so.
>>
>>John =:->
> 

John
=:->
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060110/9d533f7a/attachment.pgp