bzr commit in a heavyweight checkout does not propagate new tags

[Steve Langasek]

I've discovered that using 'bzr co' instead of 'bzr branch' for UDD merges results in later UDD import failures, because the upstream tags are not copied to the lp branch when I commit. They're visible on the upstream branch locally with 'bzr log -n0' or 'bzr tags', but on a fresh checkout from lp, the tags are not there. merging tags into a bzr checkout should propagate them to the bound branch.

[Martin Pool (mbp)]

slangasek say this is breaking all his UDD merges.

[Andrew Bennetts (spiv)]

"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.

[Andrew Bennetts (spiv)]

By the way, regardless of the cause, this workaround will probably work:

 * bzr unbind
 * bzr push LP_BRANCH
 * bzr bind LP_BRANCH

[Andrew Bennetts (spiv)]

I have branches that fix both issues (commit in heavyweight checkout not propagating tags, and tags.merge_to on a bound branch not propagating tags).

[Vincent Ladeuil (vila)]

@spiv: I don't clearly understand what has been fixed in bzr-2.2.2 there and whether we can mark this bug fixed released or not. Should we create a new bug for the reminding issues ?

[Vincent Ladeuil (vila)]

@spiv: ping ^

[Martin Pool (mbp)]

@spiv is this now fixed? Does it require any changes in lp:udd as well as in bzr?

[Andrew Bennetts (spiv)]

This was fully fixed in bzr 2.3 (and partially in the 2.2 series). It shouldn't require any changes in lp:udd (other than being run with bzr 2.3 or newer).

[PresuntoRJ (fabio-tleitao)]

Well, if the fix was supposed to solve the unpropagated tags, I am sorry to report that it still affects my 2.3.0 I am using on my systems...

I know for a fact it used to work a few versions ago (I have a tag I know a did on 14/07/2010 that has propagated to the "central repository" via merge from a branch into a checkout + commit (binded to the bzr smart server url). Not really sure what stable release was then, but I am on a Lucid, which I believe it already was back then (at least, up-to-date every week)

Is there any tests I can try? Log files to send? May a plugin be affecting my systems? Must I rebuild my repository from scratch for the fix to work? (I hope not) Is there a new META format for a repository upgrade that could mitigate the behavior? Must I get my bzr from a PPA instead?

[Andrew Bennetts (spiv)]

PresuntoRJ: please file a new bug and we can dig into what's going wrong for you there. I think you probably have a slightly different situation to the one described in this bug; if I'm wrong we can always mark the new report as a duplicate and re-open this one, but for now let's start with a clean slate.

For what it's worth, here's a shell script that shows this fix working for me:

bzr init master
cd master
bzr ci -m "First commit" --unchanged
cd ..
bzr branch master new-branch
cd new-branch
bzr ci -m "New." --unchanged
bzr tag new-thing
cd ..
bzr checkout master master-checkout
cd master-checkout
bzr merge ../new-branch
echo "Tags in master-checkout:"
bzr tags
bzr ci -m "Commit in merge of new."
cd ../master
echo "Tags in master:"
bzr tags

[Colin Watson (cjwatson)]

Accepted bzr into maverick-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

[Martin Pool (mbp)]

SRU Verification:

with 2.2.0-1 I ran spiv's script from #11 and it ends up seeing no tags in the master

with 2.2.4-0ubuntu1 it ends up seeing 'new-thing 1.1.1'

So I conclude the SRU is ok.

[Launchpad Janitor (janitor)]

This bug was fixed in the package bzr - 2.2.4-0ubuntu1

---------------
bzr (2.2.4-0ubuntu1) maverick-proposed; urgency=low

  [ Jelmer Vernooij ]
  * Update watch file to use 2.2 series.
  * New upstream release.
   + Fixes closing of leaked sockets to SSH subprocesses, which causes
     dput sftp uploads to hang. LP: #659590
   + Fixes the use of 'lp:' urls behind a http proxy. LP: #558343
   + Correctly sets the Content-Type header when http POSTing to comply
     with stricter web frameworks. LP: #665100
   + Fixes propagating tags to the master branch in a bound branch or
     heavyweight checkout. LP: #603395
   + Fixes the use of 'bzr resolve --take-other' if the file is
     involved in an unresolved text conflict. LP: #646961
   + Fixes https access with newer versions of python2.7. LP: #693880
   + Fixes crash during pack caused by a concurrent repository pack
     operation. LP: #701940
   + Fixes communication with the Launchpad web service when using
     launchpadlib >= 1.5.5. LP: #707075
   + Switches away from deprecated 'edge.launchpad.net' LP: #583667
   + Fixes resolving of content (and path) conflicts for files in subdirs.
     LP: #660935
   + Fixes nasty recursion loop while displaying branch opening error.
     LP: #687653

  [ Martin Pool ]
  * Propose for maverick SRU.
 -- Martin Pool <email address hidden> Thu, 07 Apr 2011 15:30:17 +1000