[MERGE] urlutils.rebase_url handles '..' path segments in 'url'

[John Arbash Meinel]

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

Michael Hudson wrote:
| Playing around while trying to fix bug 250418 which is to do with
| branches referring to their stacked on url by relative paths, I was
| surprised by (what turned out to be) this behaviour:
|
|>>> from bzrlib.urlutils import rebase_url
|>>> rebase_url('../bar', 'foo/quux', '')
| Traceback (most recent call last):
|   File "<stdin>", line 1, in ?
|   File "bzrlib/urlutils.py", line 670, in rebase_url
|     osutils.pathjoin(old_parsed[2], url))
|   File "bzrlib/urlutils.py", line 676, in determine_relative_path
|     to_segments = osutils.splitpath(to_path)
|   File "bzrlib/osutils.py", line 788, in splitpath
|     raise errors.BzrError("sorry, %r not allowed in path" % f)
| bzrlib.errors.BzrError: sorry, '..' not allowed in path
|
| This branch changes it to act like this:
|
|>>> from bzrlib.urlutils import rebase_url
|>>> rebase_url('../bar', 'foo/quux', '')
| 'foo/bar'
|
| I'm not sure that 'join' is necessarily the right thing to use though --
| osutils.normpath(osutils.pathjoin()) would probably work just as well.
| Something should change though I think :)
|
| Cheers,
| mwh
|

Hmm... I find the rebase_url() function pretty hard to follow. Maybe it
is just the order of arguments.

Like if you did (old_base, url, new_base)

It might be clearer that you are taking

old_base "+" url "relative to" new_base

(this is certainly outside the scope of this change, just commenting.)

I think it is fine, though. I wonder if we would want more tests.

BB:approve

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

iEYEARECAAYFAkiF+QIACgkQJdeBCYSNAAMJigCdEESMCjhlcp1u4dhg1gvr4kYq
jdUAoLP/Qxv1n9w7jPzHrhLyEYk+R7eJ
=waUx
-----END PGP SIGNATURE-----