Re: [PATCH] Issue 2318 : Inconsistent behavior with trailing '/'
On Wed, 5 Oct 2005, Madan US wrote:
> > It's possible that there are clients that don't use the '@nnn' syntax
> > for peg revisions, it's a bit of a hack after all. Those clients will
> > want to use svn_path_canonicalize so that function cannot treat '@' as
> > special.
> .... and those client will use libsvn_subr? which takes the @ as a peg
> revision marker? am not too sure...but maybe its just my ignorance...
The @rrr is a command line client thing. The peg revision part is not a
part of the path. A GUI client could have other means of specifyihng a peg
> A filename with a peg revision could be followed by a trailing slash as in
> file:///path/to/filewith_at_marker/ and expect svn to understand that
> filewith@marker is actually a filename and not a peg revisioned file.
> Similar to the way file:///path/to/filewith_at_marker@ will be treated (issue
> The rational behind the request was the following. I think its a little
> shallow myself....
> file:///path/to/filename/ is treated as if filename is a file(and not a
> dir due to the trailing slash)
> file:///path/to/filewith_at_mark/ errors out saying that 'mark' is not a
> valid revision(and hence looks like filewith@mark is not treated as a
> filename as a whole)
> The reality is
> file:///path/to/file/ is treated as file:///path/to/file
> ...thanks to svn_path_canonocalize(). Similarly...
> file:///path/to/filewith_at_mark/ is treated as file:///path/to/filewith_at_mark
> and hence errors out saying that 'mark' is not a valid revision.
> 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)
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Wed Oct 5 22:12:46 2005
This is an archived mail posted to the Subversion Dev