You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "C. Michael Pilato" <cm...@collab.net> on 2006/08/29 14:06:33 UTC
Clearing up some API ambiguity (@-syntax)
[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.)
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Clearing up some API ambiguity (@-syntax)
Posted by "C. Michael Pilato" <cm...@collab.net>.
David Glasser wrote:
> On 8/29/06, C. Michael Pilato <cm...@collab.net> wrote:
>> * 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).
>
> Perhaps opt_to_target_arrayN should be returning an array of pointers to
>
> struct {
> const char *path;
> svn_opt_revision_t start_rev;
> svn_opt_revision_t end_rev;
> }
>
> instead?
I've strongly considered this as well. Though there's no need for an
end_rev -- these are actually (path, peg_rev) tuples that we're parsing.
From a parsing perspective, I love the idea. The bum thing is that 99%
of the time, there's no explicit peg_rev provided. This means the
function is returning a list of paths in a fashion that is incompatible
with the list-of-paths that so many of the client functions accept.
So we could take this another step further. Make your recommended
structure (say, svn_location_t) more commonplace, make
svn_opt_target_array() return a list of those things, and make all the
svn_client* functions that currently accept a list of const char * paths
and one or two peg revisions accept a list of them.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Clearing up some API ambiguity (@-syntax)
Posted by David Glasser <gl...@mit.edu>.
On 8/29/06, C. Michael Pilato <cm...@collab.net> wrote:
> * 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).
Perhaps opt_to_target_arrayN should be returning an array of pointers to
struct {
const char *path;
svn_opt_revision_t start_rev;
svn_opt_revision_t end_rev;
}
instead?
--dave
--
David Glasser | glasser@mit.edu | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Clearing up some API ambiguity (@-syntax)
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 8/29/06, C. Michael Pilato <cm...@collab.net> wrote:
> 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).
I vote for the easy one ;-)
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Clearing up some API ambiguity (@-syntax)
Posted by "C. Michael Pilato" <cm...@collab.net>.
Garrett Rooney wrote:
> On 8/29/06, C. Michael Pilato <cm...@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 <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Clearing up some API ambiguity (@-syntax)
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 8/29/06, C. Michael Pilato <cm...@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.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org