Handling repeated text annotations

John Arbash Meinel john at arbash-meinel.com
Thu Feb 14 22:55:53 GMT 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Aaron Bentley wrote:
| John Arbash Meinel wrote:
|
|> | We don't currently perform true annotate merges.  --knit just uses
|> | newness information: "Was line x present in any ancestor, or was it
|> | introduced by this revision?"
|> |
|> | So if you want, I can think about it, but I don't think it's strictly
|> | relevant.
|
|> Well, this would still effect that.
|
| We don't do annotate merges any more.  Instead of using annotations, we
| do sequence matching and set operations.  So changes to the annotate
| code will not affect merge --knit at all.
|
| Aaron

So does that mean the case of:

~ A
~ |\
~ B AC
~ |\|
~ | BC
~ | |
~ | AC

Will do the "wrong" thing? (you merge B but revert it in favor of A. I suppose
it might depend on what base you pick. If you pick "B" as the base, then it
should be fine, but if you have:

~ A
~ |\
~ B AC
~ |x |
~ BC BC
~ |  |
~ |  AC

Wouldn't that cause you to use "A" as the base, and make it look like the right
side was unchanged and have "B" dominate?

Just some thoughts. I'll probably still do the "correct" thing for reasons that
Robert pointed out. (Reverting to older lines should get the text of the revert
and not the original lines.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHtMb5JdeBCYSNAAMRAt4IAJ4kkgmmtwVUz7meWTW+VNRzUqic5wCcCKuJ
TZnJzkpkuwOY04zX3tvnBaQ=
=OdK5
-----END PGP SIGNATURE-----



More information about the bazaar mailing list