"bzr upgrade" defaults to bad behaviour when the disk format is 'ahead' or 'to the side' of the default

[Tim Hatch]

I thought 'bzr upgrade' with no args would be safe, but apparently it's trying to upgrade my --dirstate-with-subtree to --dirstate without me explicitly telling it to.

Snip from IRC logs:

10:02 < jam-laptop> the default format for "bzr upgrade" is 'dirstate'
10:02 < jam-laptop> and bzr-svn would be in "--dirstate-with-subtree"
10:03 < jam-laptop> Which means there is nothing to upgrade too
10:03 < thatch> jam-laptop: so 'bzr upgrade' on a dirstate-with-subtree should be a no-op?
10:03 < jam-laptop> thatch: maybe
10:04 < jam-laptop> you can actually use 'bzr upgrade' to switch to any format you request
10:04 < jam-laptop> though some are "incompatible"
10:04 < jam-laptop> you do raise a decent point, though
10:04 < jam-laptop> that you should have to explicitly supply --dirstate
10:04 < jam-laptop> to get the error you are seeing

Steps to reproduce

mkdir temp-bzr
cd temp-bzr
bzr init --dirstate-with-subtree
bzr upgrade

(expected nothing to happen, or an 'already at most current' message if indeed there's no upgrade path)

[John A Meinel (jameinel)]

Currently we have several formats that we consider an upgrade over our default
format.

Specifically we have:

 --format=dirstate Default
 --format=dirstate-tags Branch6 and Knit1
 --format=dirstate-with-subtree Branch6 and Knit3

When you run 'bzr upgrade' you should be able to specify any formats, and it
should provide a way to downgrade as long as they are compatible.
For example, you should be able to have a 'dirstate-tags' format, and downgrade
to 'dirstate', as long as you don't have any tags.

'dirstate-with-subtree' cannot be converted to 'dirstate', because of the
root-id tracking. So it is fine if you are in a 'dirstate-with-subtree'
branch+repo, that doing 'bzr upgrade --dirstate' should fail.

However, not supplying a value 'bzr upgrade', should just tell you that you are
already in the newest format, or that the default would actually be a
downgrade, or some other user friendly thing. Rather than trying to actually
downgrade your branch, and then failing with an error message.

The "simple" workaround is just to have the "highest" format be the default for
'bzr upgrade', but that isn't practical when we release a new format.

Instead we probably need to wait to set the target format until after we have
opened the source.

Thoughts?

[Martin Pool (mbp)]

I agree it's a bug.

We could have a field on the format saying "this format is up to date", and not upgrade them unless the format was specifically given.

Or we could make it a bit more complex and give each format a field saying "by default, this format upgrades to format X", and if that's None then act as above. That would give room for upgrading between various experimental formats that support features not in the default.