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

Bug #128724 reported by Tim Hatch on 2007-07-27
2
Affects Status Importance Assigned to Milestone
Bazaar
Medium
Unassigned
Breezy
Low
Unassigned

Bug Description

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) wrote :

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?

Changed in bzr:
importance: Undecided → Medium
status: New → Confirmed
Martin Pool (mbp) wrote :

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.

summary: - "bzr upgrade" attempts to convert dirstate-with-subtree to dirstate
- without me telling it to
+ "bzr upgrade" defaults to bad behaviour when the disk format is 'ahead'
+ or 'to the side' of the default
Jelmer Vernooij (jelmer) on 2010-12-18
tags: added: upgrade
Jelmer Vernooij (jelmer) on 2017-11-08
tags: added: check-for-breezy
Jelmer Vernooij (jelmer) on 2018-05-12
Changed in brz:
status: New → Triaged
importance: Undecided → Low
tags: removed: check-for-breezy
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers