In main, resolving.

sorry I posted the wrong cset id, the correct one is: e51c0f41f271

Pushed to crew-stable (10a0bfa09ec4). Thanks.

@mjc:

to test it, just create a repo with a % in the name:
hg init foo%bar
hg clone foo%bar foobar
cd foobar
hg out
cat .hg/hgrc

I think it needs tests...

Is there something wrong with the proposed patch ?

Making title more accurate.

Here's a prototype.

mpm: how is your new config parser work coming along? any news/half-baked impl?

On Wed, 2008-06-25 at 09:17 -0400, Jonathan S. Shapiro wrote:
> On Wed, 2008-06-25 at 00:59 +0000, Michael Cahill wrote:
> > Our group has email addresses as https usernames, so they contain '@'...
> 
> I believe that this usage does not constitute a well-formed https URL.
> The traditional solution to this sort of "@ within @" problem would be
> to use something like:
> 
>   http://mjc%example.com@hg.example.com/
> 
> but of course '%' must be escaped.
> 
> In any case, we should check the well-formedness issue before accepting
> any patch to support this behavior. If the URL you want to use is
> malformed, hg should NOT (in my opinion) support it.
> 
> My concern is mainly that URLs are badly underspecified, which makes
> parsers for them crufty things already. Gunking up that code further to
> support malformed cases (if this is one) doesn't seem like a good idea.

On the other hand, all the URL parsing logic in hg is working for them
already. What's not working is our config file parser which has stupid
ideas about what % means.

On Wed, 2008-06-25 at 00:59 +0000, Michael Cahill wrote:
> Our group has email addresses as https usernames, so they contain '@'...

I believe that this usage does not constitute a well-formed https URL.
The traditional solution to this sort of "@ within @" problem would be
to use something like:

  http://mjc%example.com@hg.example.com/

but of course '%' must be escaped.

In any case, we should check the well-formedness issue before accepting
any patch to support this behavior. If the URL you want to use is
malformed, hg should NOT (in my opinion) support it.

My concern is mainly that URLs are badly underspecified, which makes
parsers for them crufty things already. Gunking up that code further to
support malformed cases (if this is one) doesn't seem like a good idea.

shap

Our group has email addresses as https usernames, so they contain '@'.  This 
leads to commands like:
  hg clone http://mjc%40example.com@hg.example.com/repo/...

The clone works fine, but it puts the URL into .hgrc verbatim, which leads to 
the following stack trace when running hg in the working directory:

  File ".../site-packages/mercurial/ui.py", line 166, in readconfig
    self.fixconfig(root=root)
  File ".../site-packages/mercurial/ui.py", line 207, in fixconfig
    pathsitems = cdata.items('paths')
  File ".../python2.5/ConfigParser.py", line 557, in items
    for option in options]
  File ".../site-packages/mercurial/util.py", line 137, in _interpolate
    option, rawval, vars)
  File ".../python2.5/ConfigParser.py", line 593, in _interpolate
    self._interpolate_some(option, L, rawval, section, vars, 1)
  File ".../python2.5/ConfigParser.py", line 634, in _interpolate_some
    "'%%' must be followed by '%%' or '(', found: %r" % (rest,))
ConfigParser.InterpolationSyntaxError: '%' must be followed by '%' or '(', 
found: '%40example.com@hg.example.com/repo'

The same would happen for any URL-encoded username.  Suggested fix attached.