Re: svn_opt_parse_path peg revision inconsistency

Karl,

Looks like you made the below discussed change to be able to protect peg revisions.

Looking through the that allowed one to protect a @ in the path or URL, do you
recall why the code results in a different revision type for

foo@ [base or head depending upon path or URL]

versus

foo [always unspecified]

http://subversion.tigris.org/servlets/ReadMsg?list=users&msgNo=32503

r15289 | kfogel | 2005-07-07 12:20:02 -0700 (Thu, 07 Jul 2005) | 17 lines

Fix issue #2317: Handle filenames containing '@' compatibly with peg
revision parsing.

Patch by: Alexander Thomas <alexander@collab.net>
           me

* subversion/libsvn_subr/opt.c
   (svn_opt_parse_path): Treat empty peg revision suffix '@' as
   '@HEAD' or '@BASE', depending on URL or local path respectively.

Blair

C. Michael Pilato wrote:
> Blair Zajac wrote:
>> If you pass a path to svn_opt_parse_path with no trailing @, then the
>> revision is svn_opt_revision_unspecified:
>>
>> /* Didn't find an @-sign. */
>> *truepath = svn_path_canonicalize(path, pool);
>> rev->kind = svn_opt_revision_unspecified;
>>
>> but if you have path with a trailing @ just to protect another @ earlier
>> in the path, then it's set to either svn_opt_revision_head or
>> svn_opt_revision_base based if the path is an URL or not:
>>
>> if (path[i + 1] == '\0') /* looking at empty peg revision */
>> {
>> ret = 0;
>> start_revision.kind = is_url ? svn_opt_revision_head
>> : svn_opt_revision_base;
>> }
>>
>> ...
>> ...
>>
>> rev->kind = start_revision.kind;
>> rev->value = start_revision.value;
>>
>> Shouldn't the @ protection just use svn_opt_revision_unspecified?
>
> Seems so to me. That looks like a real bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 17 02:24:45 2007