Re: Clearing up some API ambiguity (@-syntax)

Garrett Rooney wrote:
> On 8/29/06, C. Michael Pilato <cmpilato@collab.net> wrote:
>> [reposting this as a new thread]
>>
>> Looking at svn_opt_parse_path(), it's not clear to me how to interpret
>> the following input paths to that function:
>>
>> http://server/repos/path@{2006-03-05}
>> http://server/repos/path@%7B2006%2d03%2D05%7D ({2006-03-05}, encoded)
>> http://server/repos/path@%48%45%41%44 (HEAD, encoded)
>>
>> In fact, it occurs to me that, in general, I don't understand if we
>> consider the @-and-stuff-that-follows-it to be part of the path, or just
>> some unencoded bits we slap onto the end of properly-formatted paths as
>> a way to flatten otherwise tabular input data at the command-line UI.
>>
>> What about when the @ symbol itself is URI-encoded. Does that mean
>> something different from when it is not?
>>
>> (Sorry. I feel like I should know the answer here already, but if I do,
>> it's crouching in some dark corner in the back of my mind.)
>
> Well, all that occurs to me is "Good Question!" ;-)
>
> I'm not sure if this was really thrashed out when we first added peg
> revision support. Personally, I think it makes sense to assume that
> it's part of the URI, so you'd unencode it before looking for the @,
> but that's just off the top of my head, and I haven't actually looked
> at the implementation to see what we're doing now.

Well, there's the rub. Right now, we don't decode. And the result is
that 'svn cat URL@{date}' doesn't work at all today.

   $ svn cat http://svn.collab.net/repos/svn/trunk/CHANGES@{2006-03-05}
   subversion/libsvn_subr/opt.c:739: (apr_err=205000)
   svn: Syntax error parsing revision '%7B2006-03-05%7D'

(It was that problem I was trying to solve.)

This doesn't work today because Subversion itself first URI-encodes the
input (it being all IRI-permissive and such), and because our function
doesn't decode it again, handing off the encoded stuff to a function
that can't deal with such things.

So the answer to my question will reveal what work needs to be done:

  * If we expect the whole thing to be URI-encoded, no sweat -- I
    just make this function decode the part after the @-sign and
    I'm golden. (Really golden -- I already have a patch for this.)

  * However, if we expect the endstuffs to *not* be encoded (like,
    they aren't *really* part of the URL), then there's a bigger
    problem to solve in that opt_to_target_array() needs to stop
    encoding that stuff (and that's a trickier change to pull off).

-- 
C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand