confusing message when upgrading an already-upgraded branch

[Dato Simó]

| <dato> jam: hmmm. I have a knit shared repo with branch6 format branches. if I run `upgrade` in the branches, it complains:
| <dato> bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format.
| <dato> is that expected?
|
| <jam> dato: yeah, because it is upgrading the branch, but has nothing to upgrade
| <dato> ok
|
| <jam> It really shouldn't be telling you the meta-dir is the latest format
| <jam> I'd be happy with a bug report on that
|
| <dato> what should it say?
|
| <jam> it should tell you that the bzrdir, and branch are the latest format
| <jam> anything it is trying to upgrade
| <jam> not just the first one
| <jam> (that way it is obvious whether it is or isn't trying to upgrade the repository)
|
| <dato> ok, I'll quote this in the report

 affects /products/bzr

[John A Meinel (jameinel)]

I would really like to see the upgrade code tell you the versions of things it is trying to upgrade. Rather than the generic "meta-dir 1". Which has been the default since ... 0.8, and will probably stay the default for a long time. (It is a rather generic container, so there isn't much of a need to ever change it.)

[Christian Hudon (chrish)]

I found the message confusing too.

First of all, it's not even an error, it's a "there's nothing to be done" message. I think calling this an error makes about as much sense as say "ERROR: Tree is up to date" when running "bzr up".

Also, the "Bazaar-NG" name isn't used anywhere else now ("bzr --version" calls itself "Bazaar")... and I'm really not sure what the noun clause "branch format Bazaar-NG meta directory" means anyways. :-)

I was expecting something more like (for "bzr upgrade" without arguments): "The branch storage format is already at the default version (pack-0.92).". Maybe with a hint to use the --format argument if one wants to upgrade to something more recent than what the default format is. And in the case of brz upgrade --format=foo (when the repository is already using format foo): "Branch storage is already using format foo."

[Christian Hudon (chrish)]

Given that a lot of people will be running "bzr upgrade" in the coming few months with the release of 2.0 and the official blessing of the new "2a" format, here is the still rather unenlightening error message one gets when trying to upgrade for format "2a" a repository that is already in that format:

bzr: ERROR: The branch format Meta directory format 1 is already at the most recent format.

Can I suggest that it might be a good time to fix this buglet and include the fix in a 2.0.1 release, as part of "Bazaar 2.0 polishing" work? The error message should really talk to the user in the language they used to call bazaar. In that particular case, that message should really have the string "2a" somewhere in it.

[John A Meinel (jameinel)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Christian Hudon wrote:
> Given that a lot of people will be running "bzr upgrade" in the coming
> few months with the release of 2.0 and the official blessing of the new
> "2a" format, here is the still rather unenlightening error message one
> gets when trying to upgrade for format "2a" a repository that is already
> in that format:
>
> bzr: ERROR: The branch format Meta directory format 1 is already at the
> most recent format.
>
> Can I suggest that it might be a good time to fix this buglet and
> include the fix in a 2.0.1 release, as part of "Bazaar 2.0 polishing"
> work? The error message should really talk to the user in the language
> they used to call bazaar. In that particular case, that message should
> really have the string "2a" somewhere in it.
>

I think it is perfectly reasonable to land those sort of fixes into the
2.0.x series.

We just need someone to do it, and to have it take priority over the
other 20 things we are doing. :) (I'm currently on my 3rd or 4th
recursion of X taking precedence over Y that I'd rather be working on,
so my plate is full.)

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkq84MYACgkQJdeBCYSNAAP3VQCfQHzWx0zZsBpIKeX+IMDFTyea
MgMAn07ncQHEorVUoMXlao2sbVfEgR+8
=Pw9s
-----END PGP SIGNATURE-----

[Christian Hudon (chrish)]

Heck, if people can agree on and include in this bug report the string that the improved error message should use, I'd be willing to... err... put my keyboard where my mouth is :-) and write and submit the patch. Anyone responsible for the bazaar UI, etc. who would care to suggest something?

[John A Meinel (jameinel)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Christian Hudon wrote:
> Heck, if people can agree on and include in this bug report the string
> that the improved error message should use, I'd be willing to... err...
> put my keyboard where my mouth is :-) and write and submit the patch.
> Anyone responsible for the bazaar UI, etc. who would care to suggest
> something?
>

So I think the issue boils down to...

There are technically 4 possibly objects that upgrade would want to change.
  a) The repository format
  b) The branch format
  c) The working tree format
  d) The 'bzrdir' format

The last one is the most obscure, and is, unfortunately, the one that is
getting displayed.

It is, essentially, just the way in which things are laid out under
.bzr. Namely that a repository is at '.bzr/repository' a branch is at
'.bzr/branch', etc.

We've also only had 1 'metadir' format, which is where the specific
files for a 'repository' are clearly distinct from the files for a 'branch'.

As such reporting that the bzrdir is up to date, is the least useful, as
it is the least likely one that you would want to upgrade.

The difficulty with the reporting, is that it potentially changes based
on what is present.

If you are in a directory with only a repository, then you should
probably get:

  Repository Format is already at RepositoryFormat2a

If you are in a Branch in a shared repository, then you might expect
  Branch Format is already at...

If you are in a lightweight checkout, then probably
  WorkingTree Format is already at...

But there is also the possibility of combinations, such as in a
'standalone tree' where you have a repository, and a branch, and a
workingtree.

As such, I would think that as the internals of 'upgrade' are checking
to see what format a given object is at, it should report that to the user.

  Found Branch format XXX, not upgrading
or
  Found Branch format XXX, upgrading to BranchFormat YYY

And then the details would end up something like:

  $ bzr init --pack-0.92 test-0.92
  $ cd test-0.92
  $ bzr upgrade
    Found WorkingTreeFormat4, upgrading to WorkingTreeFormat6
    Found BranchFormat5, upgrading to BranchFormat7
    Found RepositoryKnitPack2, upgrading to RepositoryFormatCHK2
  $ bzr upgrade
    Found WorkingTreeFormat6, not upgrading
    Found BranchFormat7, not upgrading
    Found RepositoryFormatCHK2, not upgrading
    [optionally] nothing to do

We may not want to show the "Format" object names, and instead show the
'concise' name [the one you can supply on the command line]. You can
look at the difference between "bzr info" and "bzr info -v".

The main problem there is that "--dirstate" is actually a combination of
a specific wt+branch+repository combination, so you can't always map
back cleanly from a WT to a given combined form. (A given WT can map to
maybe 4 short names, etc.)

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkq87PgACgkQJdeBCYSNAANV/QCgsPQHgMxjncN2j4S5U0qgS/Vh
DEIAoM3QNBPWrZgC6imbQZNiBoUjUUin
=TkA+
-----END PGP SIGNATURE-----