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

[Jules Bean]

John Arbash Meinel wrote:
>> For merges with non-broken branches I had to preserve the merge. Worse
>> still these merges conflicted, one of them very badly, and I had to
>> preserve the conflict resolution. In the end I did the merge (with the
>> exact revid of the parent in the non-broken branch), resolved any file
>> name conflicts by hand, using bzr inventory --show-ids when in doubt
>> to see how the conflicts had been resolved in the other branch, and
>> then synced up the working tree of the reconstructed branch with a
>> working tree of a broken branch (at the corresponding revision) using
>> rsync like this:
> 
> Just to comment on this specific issue. You should probably have been
> able to do:
> 
>  bzr revert -r revid:$ORIGINAL_REVID .

but that wouldn't have worked because the REVID in question wasn't *in* 
the current tree, because that part of history was broken and bringing 
it in caused out of memory errors.

> And have it set the content of the current working tree to be identical
> to the result of the original merge. The other method being something like:
> 
>  bzr revert -r $REVNO:../old_branch .

That sounds interesting though. That might have helped.

> 
> (The key is just to give the revision that you want the tree to look like.)
> 
> I think the '.' is significant, as it tells us to not forget the merge
> parents. (Open bug that we should have a more obvious flag for that as
> well.)

Yes, I knew about bzr revert . (well I didn't, but someone told me) but 
I didn't know about $REVNO:../other-branch.

Interesting.

Jules