one more observation in case it helps... this problem seems limited to
filenames with @ as the first character only... if the @ comes after the
first, things seem ok to me:
i.e. this works in 1.5.1:
mkdir dir
svn add dir
svn ci -m test dir
touch dir/a_at_file
svn add dir/a_at_file
svn ci -m test dir/a_at_file
-Scott
On Wed, 27 Aug 2008, Julian Foad wrote:
> On Wed, 2008-08-27 at 16:56 -0400, Karl Fogel wrote:
>> Julian Foad <julianfoad_at_btopenworld.com> writes:
>>> No. It is by design that this function returns the entire peg-specifier
>>> part of the input string, rather than a canonical peg specifier derived
>>> from it. The callers rely on this.
>>>
>>> Now, it's maybe not a great design, but that's how it is at the moment.
>>>
>>> And the doc string is not clear on this point.
>>
>> So in this instance, the caller is simply using the returned values
>> wrongly? (Forgetting for the moment the possibility of improving the
>> design -- I'm just talking about whether the caller is working correctly
>> with the API as it stands today.)
>
> This instance being svn_client_args_to_target_array()? No, that's using
> it correctly. It just splits off the peg-specifier part of the string
> temporarily, canonicalises the rest, and the re-appends the
> peg-specifier string, to leave a result string which is still properly
> peg-escaped (i.e. may end with "@" or with "@PEGREV" or with neither,
> just as it did on input).
>
>> Who is supposed to be responsible for peg-rev escaping? That is, if
>> someone puts "@" on the end of a path (presumably for the sole purpose
>> of establishing that there is *no* peg rev here), what API is
>> responsible for handling that?
>
> svn_opt_parse_path() - the API that parses the string into a path part
> and a peg. (Not this one that "splits" the string.)
>
> I notice now that svn_opt_parse_path()'s doc string doesn't mention its
> behaviour when just a trailing "@" is found, and furthermore the sole
> example of this shown in its doc string appears to be wrong, showing
> that the revision "base" would be returned in this case.
>
> - Julian
>
>
>> I would have thought it would be svn_opt__split_arg_at_peg_revision().
>> That is, it hadn't occurred to me to consider the final "@" to be "the
>> entire peg-specifier part of the input string". Rather, I'd have
>> considered it a marker that indicates that there is no peg-specifier
>> here at all. Clearly I'm wrong, but I still don't quite understand what
>> the system is supposed to be, then... Do you understand it?
>>
>> -Karl
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-08-28 05:11:22 CEST