bzr heads: how to kill uncommited revisions?
John Arbash Meinel
john at arbash-meinel.com
Sun Jul 30 23:05:30 BST 2006
Alexander Belchenko wrote:
> I like to use shared repository for development. Especially for my work
> on bzr.dev. I often uncommit revisions. Or simply delete wrong way
> Now I have 'heads' plugin that able to show all revisions that don't
> have childs. And it show all uncommitted revisions too. So I suppose
> that uncommitted revisions don't deleted from shared repo (may be it's
> true and for standalone branches).
> Is there exist way to actually kill unnecessary heads?
How dead do you need them to be? The easiest way to do it, is to just
re-branch all of your stuff into a new location. The branch (and push
and pull) code only copy across referenced entries. And in the new
location, everything will be truly cleaned out.
If you want to clean things up in place, and you need the contents of
all of the texts that made up that revision be removed from all knits,
it is kind of tricky. I can outline the process if you really want to do
If all you want is for them not to show up in the list of 'heads', then
you can just rewrite the revisions.kndx index file. And leave out the
lines that reference the revisions you don't want.
You need to be a little careful, because knit indexes are dictionary
compressed based on order. So when you remove a line, all subsequent
references need to be decremented.
My recommendation would be to read the knit index, and parse it out so
that each reference is changed back into a real revision id.
Then remove the entries you don't want, and write out the index again.
If you want to truly nuke the information...
The index tells you where in the .knit file the bytes are contained. So
all you have to do is overwrite those bytes with null, or really anything.
So you can nuke the revisions.knit information easily. Then you need to
read the information in the inventory so you know what texts you need to
nuke, and then run around and zero out all the contents and rewrite all
of the knit indexes that you come across.
If you want example code, it is actually something like the fetch code,
which figures out what exists in one knit that doesn't exist in the
other, and copies it across. Only know you want to find out what doesn't
exist (or what does) in a given set, and then delete it.
So truly nuking information is a little bit difficult. But if you write
something that can read a generic index file (.kndx) and remove entries
safely, it isn't a lot more work to tack on the rest.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060730/bb646d73/attachment.pgp
More information about the bazaar