bzrlib.info._repo_relpath confused about urls vs paths

[Marien Zwart]

Not sure if this qualifies as a bug since I cannot get it to misbehave, but this code seems to be passing urls to osutils functions expecting paths.

_repo_relpath is called with the "base" attributes of two transports. This attribute is an url according to the documentation and some experimenting. It passes this to the osutils function normalizepath which expects a filesystem path. The url it receives is interpreted as a path relative to the current working directory (turning 'file:///home/marienz/bzr/' into u'/usr/portage/distfiles/file:/home/marienz/bzr' for example). The resulting "normalized" paths are passed to osutils.relpath which strips off the working directory again as a "common prefix" of the two paths.

While this code works it looks like it at least deserves a comment on *how* it works. There may even be a bug lurking here (I managed to confuse a function of my own based on this one by removing the cwd, and I am not entirely sure if this code deals with non-ascii paths correctly).

[Aaron Bentley (abentley)]

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

Marien Zwart wrote:
> Public bug reported:
>
> Not sure if this qualifies as a bug since I cannot get it to misbehave,
> but this code seems to be passing urls to osutils functions expecting
> paths.

I'm having trouble imagining how to make it misbehave, but it doesn't
set a good example. Now that we have urlutils.relative_url, we should
use that instead.

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

iD8DBQFFhqQe0F+nu1YWqI0RAqojAJsEMdunzEK9bRg7jHzyT5MncHeeuwCdF59v
G0y8hK9NCTtEdorVC5aEQ54=
=Bsrb
-----END PGP SIGNATURE-----