bzr push from 2a to older format may corrupt branch?

Bug #562380 reported by Toshio Kuratomi on 2010-04-13
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Bazaar
Critical
Andrew Bennetts
2.0
Undecided
Unassigned
2.1
Undecided
Unassigned
Launchpad itself
High
Unassigned
bzr (Ubuntu)
Undecided
Unassigned
Lucid
Undecided
Unassigned

Bug Description

I had an older branch on launchpad that I did some work on today. Somewhere along the line it seems to have gotten corrupted as I now get tracebacks when doing bzr log, bzr diff -r latest:1, and several other commands. (Will attach .bzr.log for those)

The launchpad branch is here. It was not in 2a format when I started work this morning but as part of trying to get rid of the tracebacks, I pushed the upgrade branch button in launchpad:

  https://code.launchpad.net/~toshio/bzr-gtk/handle-dirty-patches

The branch I have locally is in 2a format. I've pushed that to another location on launchpad in case it's useful:

  lp:~toshio/bzr-gtk/test-push

bzr client version 2.0.5

This is more or less what I've done (reconstructed from my shell's history)

    bzr merge # Pull latest revisions in from lp:bzr-gtk
    bzr commit
    vim diff.py # Make a small addition to diff.py
    bzr status
    bzr diff
    bzr commit
    # Decide I should have been more verbose in my comments
    bzr uncommit
    bzr status # Check that my changes are present
    vim diff.py # Add extra comment
    bzr commit
    bzr push # remembered location lp:~toshio/bzr-gtk/handle-patch-fix

I then checked what was going on on launchpad and found that the web viewer wasn't showing the latest revisions so I decided to check what the branch showed when I branched it.

    cd ..
    bzr branch lp:~toshio/bzr-gtk/handle-patch-fix
    cd handle-patch-fix
    ls
    bzr log
    # Traceback

After getting the traceback I tried a variety of things. It looks like things that touch history (bzr diff -r latest:1, bzr log) are hitting the corruption. Things that don't touch history (bzr status, bzr info) are not. I also pressed the button in the launchpad UI to upgrade the format as I thought that it migt be something in the on-the-fly repository conversion. (Note: when I branch lp:~toshio/bzr-gtk/handle-patch-fix currently, it does not retrieve a 2a format branch even though the launchpad UI says the update has finished).

Related branches

Toshio Kuratomi (toshio) wrote :
Toshio Kuratomi (toshio) wrote :

One further note, I've submitted the changes I was working on here in another branch. So you can play around with these however you like. I won't touch them until this bug is closed.

Andrew Bennetts (spiv) wrote :

This is pretty serious. I'm tempted to mark it Critical.

It seems to be pretty easy to reproduce some serious misbehaviour:

$ bzr branch lp:~toshio/bzr-gtk/handle-patch-fix
Doing on-the-fly conversion from <RepositoryFormat2a> to (remote).
This may take some time. Upgrade the repositories to the same format for better performance.
Branched 667 revision(s).
Transferred: 2882kB (50.9kB/s r:2880kB w:2kB)
$ bzr check
[CRASH: XML SyntaxError in read_revision_from_string]
$ bzr upgrade
[ditto]

The problem appears to be that lp:bzr-gtk is 2a, and ~toshio/bzr-gtk/handle-dirty-patches is 1.9-rich-root, but stacked on that 2a branch. Fetching handle-dirty-patches retrieves 1.9-rich-root, but apparently has broken data. So probably this bug involves stacking?

I'm not sure yet when the corruption is first introduced. Maybe by the LP upgrade?

Changed in bzr:
importance: Undecided → High
status: New → Confirmed
Martin Pool (mbp) on 2010-04-15
Changed in bzr:
importance: High → Critical
Andrew Bennetts (spiv) wrote :

Fetching the handle-patch-fix branch via sftp, upgrading it, and then editing branch.conf to stack it on a local copy of trunk produces an undamaged branch.

So the primary issue here is that "bzr branch lp:~toshio/bzr-gtk/handle-patch-fix" is doing the wrong thing.

A secondary issue is that Launchpad's upgrade button for your branch seems to have failed.

And also, and I think crucially, our 'cannot stack in this situation' check
is not working. That may be whats breaking the upgrade button too.

Andrew Bennetts (spiv) wrote :

The 'cannot stack' check turned out to be missing from RemoteRepository. The code duplication between RemoteRepository and Repository bites us again :(

I've just pushed up a branch that fixes that. Now an attempt to fetch from that branch will give the ugly-but-correct result:

$ ./bzr branch lp:~toshio/bzr-gtk/handle-patch-fix /tmp/should-break
bzr: ERROR: RemoteRepository(bzr+ssh://bazaar.launchpad.net/~bzr-gtk/bzr-gtk/trunk/.bzr/)
is not compatible with
RemoteRepository(bzr+ssh://bazaar.launchpad.net/~toshio/bzr-gtk/handle-patch-fix/.bzr/)
different serializers
Transferred: 2kB (0.2kB/s r:1kB w:1kB)

i.e. it refuses to open the branch. That's what we want, because if the branch is opened then we can get garbage when we fetch from it, which results in the errors in this bug.

Andrew Bennetts (spiv) on 2010-04-16
Changed in bzr:
status: Confirmed → In Progress
assignee: nobody → Andrew Bennetts (spiv)
Andrew Bennetts (spiv) wrote :

By the way, your handle-patch-fix branch appears to be intact when upgraded manually. And your 'test-push' branch passes 'bzr check' as well. So no lasting harm appears to have happened to your repositories.

I'm about to submit a merge proposal that I believe fixes the root issue, which as discussed above is that "bzr branch lp..." should have failed for you in this case, because handle-patch-fix needed upgrading to match its stacked-on branch before it was usable.

I don't see any obvious reason from my investigations that would explain why the upgrade you tried via Launchpad's web interface failed. I'll add the launchpad-code project to this bug and see what those guys think.

Andrew Bennetts (spiv) wrote :

Launchpad-code guys: see my comment #7: the reporter tried to upgrade a stacked branch via the web UI, and it failed.

Robert Collins (lifeless) wrote :

I suggest filing a new bug for the ugprade issue, on lp-code

Andrew Bennetts (spiv) wrote :

Fix has landed in trunk. Will look at backporting to the other stable releases.

Changed in bzr:
status: In Progress → Fix Released
Tim Penhey (thumper) on 2010-04-21
Changed in launchpad-code:
status: New → Triaged
importance: Undecided → High
Vincent Ladeuil (vila) on 2010-04-23
Changed in bzr:
milestone: none → 2.2b3
Tim Penhey (thumper) wrote :

Fixed with the bzr 2.2 rollout into LP.

Changed in launchpad-code:
status: Triaged → Fix Released

Accepted bzr into lucid-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!

Changed in bzr (Ubuntu Lucid):
status: New → Fix Committed
tags: added: verification-needed
Jelmer Vernooij (jelmer) on 2011-05-21
Changed in bzr (Ubuntu):
status: New → Fix Released
Launchpad Janitor (janitor) wrote :

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

---------------
bzr (2.1.4-0ubuntu1) lucid-proposed; urgency=low

  * Update watch file to use 2.1 series.
  * New upstream release.
   + Fix file descriptors leaks in dirstate compiled extension. LP: #583486
   + Refuse to stack on repositories in incompatible formats. LP: #562380
   + Don't delete nested trees/repos. LP: #572098
   + Fix 'bzr switch' crash when a 'ConfigurableFileMerger' is used. LP: #559436
   + Fix compatibility with older smart servers. LP: #528041
   + Fix symlinks addition. LP: #192859
   + Properly unversion children of unversioned directories. LP: #494221
   + Lock configuration files in '~/.bazaar' for updates. LP: #525571
   + Fix 'bzr commit <symlink>'. LP: #128562
   + Fix `lp:` urls when behind an http proxy. LP: #558343
   + Stop using edge.launchpad.net. LP: #583667
 -- Max Bowsher <email address hidden> Tue, 17 May 2011 09:54:17 +0100

Changed in bzr (Ubuntu Lucid):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers