On Thu, 6 Oct 2005, Madan U Sreenivasan wrote:
> On Thu, 2005-10-06 at 01:40, Peter N. Lundblad wrote:
> > On Wed, 5 Oct 2005, Madan US wrote:
> [snip]
> > > Since its svn_path_canonicalize() that causes the symptom in the first
> > > place, I have tried to make it understand (a little intelligently) that
> > > the user might have used the trailing / intentionally - if the last
> > > segment of the filename contains an @ symbol (The trailing slash
> > > wouldnt make sense if what comes after that @ is a revision number).
> > > Hence the behavior of using a trailing / should be treated as if an
> > > trailing @ was present.
> > >
> > I haven't looked at this in detail, but to me it sounds like the path is
> > canonicalized *before* the peg revision is stripped. Couldn't you just
> > reverse the order? (Just a suggestion)
> Yes, and its called in the following sequence...
> svn_cl__proplist()->svn_opt_args_to_target_array2()->svn_path_canonicalize()
>
> peg revision processing happens here...
> svn_cl__proplist()->svn_opt_parse_path()
>
> where the former is (rightly) done before the latter. So, we cant
> reverse the order.. :(
>
I think it is wrong for svn_opt_args_to_target_array2 to canonicalize the
paths, because they aren't paths, they are paths plus an optional peg
specification. There also is code to "canonicalize the case", which
obviously doesn't work if there is an @rev at the end of the "path".
Regarding the Issue at hand, it seems hackish, as philip pointed out, to
use a trailing slash to support filenames with @. Why don't we have an
escaping mechanism for this? (Rethorical question, of course.)
Thanks,
//Peter
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 6 13:23:09 2005