| 2006-10-11 00:13:48 |
John A Meinel |
bzr: statusexplanation |
|
This still is the case in bzr-0.11. I looked at the ancestry graph, and I don't think the specific problem is that you split off of the event branch rather than the main dev branch. That might have made things simpler, but part of what happened is that we have 3 branches, dev, event, and storage. storage comes from event.
In preparation for something, you merged dev into storage. And then in the next revision, you merged event into dev. Which creates some weird crossings in the ancestry. This isn't strictly wrong, but if you had merged dev into storage *after* you merged event into dev, things probably would have been cleaner.
If you do 'bzr merge --show-base', you can see that both trees think that you removed some #define lines.
Only in one of them you also added '#include "base64.h"', and the other one just has a blank line.
Most likely, these lines were removed in the event branch, but because of the base that got chosen, it shows up as a change in both branches.
Now, if you use 'bzr merge --merge-type=weave' lib/proxy.c has no conflicts. Because that uses a more advanced mechanism, which knows that the lines being removed were removed in the ancestry of both branches, so the new lines replace the existing ones.
We have the ability to do weave merging (annotation based merging), and we have considered making it the default. It is just something that we need a little more experience with, because the output can be a bit different than the default diff3-style merging.
It might also be possible that a per-file ancestry graph would resolve this (also something we are considering).
I'll upload a truncated (but still large) ancestry graph of the involved revisions in a second. |
|
