Error messages should not include internal filenames below bzrdir

[Alexander Belchenko]

Some error messages expose to user internal bzr directories.
I think bzr should not show their own internal info to user.

Examples (mydev is my treeless repo):

E:\Bazaar\mydev>bzr pull E:\work\selftest.win32-0.16\
bzr: ERROR: Not a branch: E:/Bazaar/mydev/.bzr/branch/

E:\Bazaar\mydev\selftest.win32>bzr merge E:\Bazaar\mydev\selftest.win32-0.16\
bzr: ERROR: No WorkingTree exists for file:///E:/Bazaar/mydev/selftest.win32/.bzr/checkout/.

In both cases error message talk about bzr internals.
This is confusing even me, because it's not explains
real reasons of error (incorrect usage of commands).

I think it's better to say something related to actual problem,
i.e.

In case 1:

E:\Bazaar\mydev>bzr pull E:\work\selftest.win32-0.16\
bzr: ERROR: Not a branch: E:/Bazaar/mydev/
You cannot pull to treeless root of shared repository.

In case 2:

E:\Bazaar\mydev\selftest.win32>bzr merge E:\Bazaar\mydev\selftest.win32-0.16\
bzr: ERROR: No WorkingTree exists for E:/Bazaar/mydev/selftest.win32
You cannot merge to treeless branch.

[Aaron Bentley (abentley)]

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

Alexander Belchenko wrote:
> Public bug reported:
>
> Some error messages expose to user internal bzr directories.
> I think bzr should not show their own internal info to user.

I agree with this. In particular, class names like BzrBranch5 show up
way too frequently in error messages.

> I think it's better to say something related to actual problem,
> i.e.

It is always simpler to give factual errors than to give helpful ones.

> E:\Bazaar\mydev>bzr pull E:\work\selftest.win32-0.16\
> bzr: ERROR: Not a branch: E:/Bazaar/mydev/
> You cannot pull to treeless root of shared repository.

The presence of trees has nothing to do with whether you can pull. It's
the presence of branches that matters. This is what I mean about
factual vs helpful. This message may be helpful to some, but not to
everyone, because not everyone has trees associated with their branches.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF9VfN0F+nu1YWqI0RAlgCAJ4vnXi5vMOELpgEsn3qZLo9Wa3TNwCeMwcx
d92hUUabjJ2AsXLRGasge9I=
=DWdx
-----END PGP SIGNATURE-----

[John A Meinel (jameinel)]

It is certainly reasonable to go through our use cases (including failures), and make sure we have reasonable messages to the user.

In fact, we should probably have a high priority bug for that.

[John A Meinel (jameinel)]

I created a spec for this:
https://blueprints.launchpad.net/bzr/+spec/polish