Infinite loop: downgrade of working tree format never finishes

[Andrew Bennetts]

This session loops infinitely:

andrew@steerpike:/tmp$ bzr init-repo --1.9 1.9-repo
Shared repository with trees (format: 1.14 or 1.9)
Location:
  shared repository: 1.9-repo
andrew@steerpike:/tmp$ cd 1.9-repo
andrew@steerpike:/tmp/1.9-repo$ bzr init --1.14 1.14-tree
Created a repository tree (format: 1.14)
Using shared repository: /tmp/1.9-repo/
andrew@steerpike:/tmp/1.9-repo$ cd 1.14-tree/
andrew@steerpike:/tmp/1.9-repo/1.14-tree$ bzr upgrade --1.9
starting upgrade of file:///tmp/1.9-repo/1.14-tree/
making backup of file:///tmp/1.9-repo/1.14-tree/.bzr
  to file:///tmp/1.9-repo/1.14-tree/backup.bzr
[###################-] checking repository format 1/1

i.e. upgrading (or downgrading) a checkout/branch to the same format as the shared repo it is contained in seems to get stuck in an infinite loop.

[Matthew Fuller (fullermd)]

Maybe this is bug 390512?

[Andrew Bennetts (spiv)]

fullermd: yes, you're right. I'll mark the other as a dupe of this, as this report has clear instructions on how to reproduce.

[Matthew Fuller (fullermd)]

It's a little misleading though; you don't need any sort of repo to reproduce it. You can do it just with standalone trees.

It happens any time you try to 'downgrade' the WT format. e.g.,

% bzr init --format=2a ; bzr upgrade --format=1.14-rich-root

works just fine (same WT format), but then going on to

% bzr upgrade --format=1.9-rich-root

fails. Or doing the 1.9 straight from 2a. Branch or repo formats don't seem to matter. It just spins forever:

0.756 opening working tree '/tmp/bzr/A'
0.779 opening working tree '/tmp/bzr/A'
0.783 opening working tree '/tmp/bzr/A'
0.788 opening working tree '/tmp/bzr/A'

[Andrew Bennetts (spiv)]

Right. The triggering condition is, I think, "bzr upgrade --format=X" when the repo is already format X, but the working tree is not.

So your example the attempts 1.14-rich-root -> 1.9-rich-root triggers it because the repo format for those two is identical, but the working tree is not.

Possibly the fact that there are multiple format handles that use the same repo format (e.g. 1.14-rich-root/1.9-rich-root) adds a bit of confusion.

Perhaps there are other cases. If there are, I'm inclined to let whoever fixes this bug decide if they think this bug report is sufficient or if more should be created.

[Matthew Fuller (fullermd)]

> Right. The triggering condition is, I think, "bzr upgrade
> --format=X" when the repo is already format X, but the working tree
> is not.

No, it does the same thing when trying to go direct 2a to 1.9-r-r. It
appears purely WT related. Repo, shared or otherwise, doesn't give
any appearance of mattering.

[Alexander Sack (asac)]

bug 445857 was marked as dupe ... not sure though we seee this on downgrade. I am now seeing this too on another not so recent branch, which has Standalone tree (format: unnamed) in bzr info.

[Alexander Sack (asac)]

the test branch that shows my behaviour is: 1. branch lp:~mozillateam/firefox/firefox-3.7.head-broken or lp:~micahg/firefox/firefox-3.7-20091006

this does not finish when using bzr upgrade --pack-0.92

[Alexander Sack (asac)]

i am also seeing the same on lp:ntrack. However, this is a pretty new branch - still its "unnamed". What's going on?