Difficulty of reconstructing a branch whilst deleting/fixing a broken revision

[Jules Bean]

Aaron Bentley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Jules Bean wrote:
>> For merges with other sub-branches of the *broken* revision, I
>> couldn't merge (that would bring the large file back in)
> 
> It would bring it in temporarily, but if you didn't commit the revision
> as a merge (e.g. revert --forget-merges), then it would not be part of
> history and would be easy to get rid of.

OK, I didn't think of that. I think I didn't know about --forget-merges 
at that point in my exploration. This would be painful though, involving 
bzr repeatedly suffering out of memory errors while it tries to cope 
with the big file.

> 
>> Actually I think this was misguided anyway since bzr shelve would have
>> lost the file-ids of added files,
> 
> No, it preserves file-ids.

Wow. So it does. I'm not sure how I came to the conclusion it doesn't.

>> On some sufficiently complex changesets, bzr shelve doesn't work
>> even though bzr commit does.
> 
> I'm not sure how you got that error, but it's because it was trying to
> "bzr add" a file that didn't exist.

So this part sounds like a real bug, then. And possibly an important 
one. I still have the broken repo, and the fixed one, and most 
intermediate states too. I can't share the whole thing publically 
(sorry!) but is there something I can do to help pin this down?

>> Explicitly support an externalisable 'rich diff' which includes file
>> renames, additions, deletions and binary changes. This is probably
>> just the 'shelve' format, and not very different from the external
>> patchset format.
> 
> We already have merge directives and bundles.  I don't think we want
> another format.  The only reason you want this is to avoid preserving
> history, but we want our tools to preserve history wherever possible.
> 
> Perhaps a "merge --no-history" option would serve better.  It would be
> an explicit way to apply changes without preserving history, and would
> work with our existing formats.

That would be no different from a merge followed by a forget-merges, 
would it? The problem I need to solve involved preserving some history 
but changing (or forgetting) other aspects of it.

Jules