[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] Issue 2318 : Inconsistent behavior with trailing '/'

From: Peter N. Lundblad <peter_at_famlundblad.se>
Date: 2005-10-05 22:10:44 CEST

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
> #2317)
> 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)
> but
> 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: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 5 22:12:46 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.