Comment 4 for bug 40412

There generally isn't a clean base for weave merge, because it is a conglomerate of the whole ancestry. So I'm not 100% sure what we would put in the file.

That said, we have some options for his use case

1) bzr merge --weave -Dmerge

Will drop a file named
FILENAME.plan

Into the working tree. This has a detailed accounting of all the lines that we evaluated as part of doing the merge. I don't think it has the actual revision id annotations, though that could probably be added. Instead it tells you what lines existed on what side, what has been superseded, etc. I mention it mostly because it exists now, and gives a more detailed account. Then again, I thought it had the revision ids, which it doesn't seem to have after all. (I know it has to compute them, so I thought it would have listed them)

2) bzr merge --merge3
If we change this to do per-file graph merging, I think it will handle more cases where Guilhem uses --weave now, and still gives him a .BASE that he can use.

3) Output the conglomerated weave as .BASE. We could build the Weave in memory, and then use the same "activate lines in THIS + OTHER" and write out what that generates, possibly with the weave's revision id annotation. We don't really want the revision ids for someone trying to use a 3-way merge tool. But honestly using a 3-way merge tool on the results of Weave isn't particularly relevant either.