What happens to patches sent upstream to CVS and re-imported from there?

Hello Norbert. Long time no see!

This is a very good question. There are a couple of techniques you can use to help you keep track of patches merged upstream and through a code import. I plan to document them soon, but I do not have the time today. I will keep you posted.

I don't think this is actually answered, though.

Re-opening the question.

If the diff that you sent upstream was merged without alterations, and that code is not subsequently altered in the external mainline, then bzr should cleanly merge in those changes, and no longer show this as a difference.

However if the code was modified in some small way, then when remerging the mainline imported code, you will most likely get conflicts during the merge that you will have to resolve by hand.

Oops, I forgot about this question.

Generally, to do what you are doing, you need to recreate the information that was lost when your patch was applied to CVS. The way to do that is to use an intermediate branch whose only purpose is to add ancestry information to the import branch.

Here is how I would do it:
 0. The Launchpad import branch is lp:/hello
 1. My local feature branch is hello/myfeature
 2. After the patch from myfeature is applied to CVS, and the Launchpad import is updated, I create a local branch hello/cvs-merges, which is lp:/hello at the revision where myfeature was merged into CVS. Something like "bzr branch -r 1234 lp:/hello hello/cvs-merges".
 3. Into cvs-merges, I "bzr merge hello/myfeature". If the change was applied in CVS without modification, this should not conflict thanks to the diff3 logic. If there were changes, there will be conflicts. I do NOT commit yet.
 4. In the cvs-merges tree, I do "bzr revert ." (the final dot is important). That reverts all tree changes, but does not remove the pending merge information. Then "bzr commit -m 'Sync ancestry with myfeature'".
 5. In the future, when pulling CVS changes, first merge them into the hello/cvs-merges branch, then merge that branch into your developement branches.

I hope you get the idea.

That will fix the ancestry data, and will let "bzr missing" output something more meaningful. That will also allow diff3 merges to behave more sensibly if you have another outstanding branch that depends on your hello/myfeature branch.

However, that will not reconcile the annotation data: the cvs-merges branch will not restore the information of which lines were modified by hello/myfeature. So weave merge will not work well.

I believe that merging the other way around (the cvs import of the revision that merged your patch INTO the revision the patch came from in hello/myfeature) would do a better job at restoring the annotation data and keeping weave merge useful.

Hope this helps.