Comment 2 for bug 603395

"commit" in the summary of this bug is a red herring, I think, although without knowing more details about what Steve is doing it's hard to be sure.

It's true that commit doesn't propagate new tags, but as 'bzr tag' refuses to work on bound branches with an unreachable master branch, I think that's probably ok. Although there *is* a bug in this scenario:

 * there is a master branch M, a heavyweight checkout of M called C, and a fork of M called F.
 * add a commit to F, and tag that new commit T
 * "bzr merge F" in C, and "bzr commit --local" it.
 * now tag T exists in C now M.
 * "bzr update" in C
 * "bzr commit" in C.
 * now C and M are supposedly synchronised, but T exists in C but still not in M.

However, I don't think that is this bug, although that is a bug worth fixing. I'll file a separate bug report for that.

I believe the immediate cause of *this* bug is that the bzr-builddeb calls the 'branch_obj.tags.merge_to' API directly, but that API doesn't propagate tags from a bound branch to the master branch.

I think it's reasonable for bzr-builddeb to expect that behaviour, though. Otherwise there's no good API for plugins to use in this case, and other related APIs like 'branch_obj.tags.set_tag' do propagate. So I'll fix merge_to take the master branch (if any) into account. This is perhaps a little hairy if the master branch has a different tags dict to the bound branch, but that's all the more reason why bzrlib should take care of this instead of a plugin.