[PATCH 2 of 3] Fix hgwebdir collections when the baseurl option is set

[Emanuele Aina]

> > > I thought about it, but unfortunately urljoin
> > > 1) doesn't always add a path level (which is what we want here):
> > >    urlparse.urljoin('http://example.com/bar', 'foo')
> > >    'http://example.com/foo'
> > 
> > Maybe we always add a /-prefix to foo? Especially if we're sure foo doesn't have
> > one itself (as is true in the case of repository identifiers).
> 
> A '/'-prefix to foo will make urljoin treat it as an absolute url:
>   urlparse.urljoin('http://example.com/bar/baz', '/foo')
>  'http://example.com/foo'
> 
> We need to add the slash as a suffix to the base url, explictly checking
> if it already ends with one of those to avoid duplicating it.

According to http://www.python.org/dev/peps/pep-0333/#url-reconstruction
it should be sufficient to do this: 
  url += quote(environ.get('SCRIPT_NAME',''))
  url += quote(environ.get('PATH_INFO',''))

(of course replacing 'environ' with 'req.env' in hgwebdir code)

This is because it is assumed that the two variable are empty or they start
with a slash.

Then we could simply add '/'+name, as we can assume that repository names
will not start with a slash.

A potential problem with this approach is explained here:
http://mail.python.org/pipermail/web-sig/2007-January/002475.html

It says that if SCRIPT_NAME ends with a slash, appending PATH_INFO will
yield a doubled slash at the joint.

The most plausible solution is to make sure that SCRIPT_NAME does not
end with a slash, removing it if necessary.

Does it sound as a sane approach?

Can the previous patches be applied nonetheless, as I'm not sure when I
will have another bit of time to devote to improve this and they already
fix the bug? :(

Thank you!

-- 
Buongiorno.
Complimenti per l'ottima scelta.