Re: [Monotone-devel] mtn:// URIs

[Thomas Keller]

Am 29.08.10 18:47, schrieb Timothy Brownawell:
> Short version: I'd like to use ';' as a URI argument separator, and
> error out if both a query parameter and a separate include pattern are
> given. Are there any objections to this?
> 
> 
>> $ mtn sy
>> mtn://mtn-host.prjek.net/webohst?'net.venge.monotone.{viewmtn,contrib.{webhost,usher}}*'
>>
>> mtn: misuse: invalid pattern 'net.venge.monotone.{viewmtn': unmatched '{'
> 
> Using ',' as a URI argument separator conflicts with braces in
> globishes. This could be worked around by making the URI parser ignore
> ',' if it's inside braces, but that's kind of icky. I'd prefer to use
> something like ';' as a URI separator instead. Sure it requires quoting,
> but you'll probably need to quote your URIs anyway...

Uh oh, yes, go ahead and change ',' to ';' as branch separator then. I
wonder how this one could slip through - blame me and the missing tests
for it...

>> $ echo
>> mtn://mtn-host.prjek.net/webohst?net.venge.monotone.{viewmtn,contrib.{webhost,usher}}*
>>
>> mtn://mtn-host.prjek.net/webohst?net.venge.monotone.viewmtn*
>> mtn://mtn-host.prjek.net/webohst?net.venge.monotone.contrib.webhost*
>> mtn://mtn-host.prjek.net/webohst?net.venge.monotone.contrib.usher*
> 
> If you have globishes with braces and *don't* quote them, the shell will
> expand them. This was OK with separate include patterns, but it does bad
> things if the globish is a URI parameter (and would be bad in a separate
> *exclude* option as well)...
> 
>> $ mtn sy
>> mtn://mtn-host.prjek.net/webhost?net.venge.monotone.{viewmtn,contrib.{webhost,usher}}*
>>
> 
>> $ mtn ls vars
>> known-servers: mtn://mtn-host.prjek.net/webhost
>> a52f85615cb2445989f525bf17a603250381a751
>> server-exclude: mtn://mtn-host.prjek.net/webhost
>> server-include: mtn://mtn-host.prjek.net/webhost
>> {mtn://mtn\-host.prjek.net/webhost?net.venge.monotone.contrib.webhost*,mtn://mtn\-host.prjek.net/webhost?net.venge.monotone.contrib.usher*}
>>
> 
> The entire URI gets turned into multiple arguments that each look like a
> URI. Then the query parameters on the first copy get ignored by mtn
> (when you give what it thinks are separate include parameters, it uses
> those exclusively), and you end up with an include pattern where all
> alternatives start with "mtn://...".
> 
> This could be solved with some fragile magic to collapse the multiple
> arguments back to one, or by erroring out if you have both a query
> parameter and separate include patterns (I prefer this option), or by
> erroring out if a separate include pattern looks like a URI.

The error detection in the latter case is not less fragile than the
magic collapsing, but I don't see a better fix for this at the moment
either. Place a FIXME at the point though that the code can be removed
in the next major version when we really remove the SERVER
BRANCH_PATTERN syntax, because then it should be clear that we only
accept zero or one argument to the function.

Thanks for pointing these issues out!

Thomas.

-- 
GPG-Key 0x160D1092 | address@hidden | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en

signature.asc
Description: OpenPGP digital signature