> -----Original Message-----
> From: Lorenz [mailto:lorenznl_at_yahoo.com]
> Sent: woensdag 16 november 2016 15:02
> To: users_at_subversion.apache.org
> Subject: Re: discrepancies between 'svn -R list' and 'svn -R propget' (on
> windows using TSVN build command line client)
>
> Bert Huijben wrote:
> >[...]
> >The difference is that 'svn ls' is really a repository operation, working
on
> >URLS (or part of urls). On URLs we always use the url / platform
independent
> >'/' separator.
> >
> >'svn propget' usually works on local paths, in which case we use the
local
> >path (or technically 'dirent') separator, which is a '\' on Windows.
> >
> >This behavior was explicitly implemented this way years ago.
> >[...]
>
> ok, that explains the slash mystery 8-)
>
>
>
> but what about the leading subpath vs. no subpath difference?
>
> svn -R ls path/subpath
>
> file1
> subsubpath/file2
> ...
I don't think this was designed behavior... But it follows from the previous
answer: we just return the items relative from the url that you listed.
There is no easy way to do this differently as local paths might not match
remote paths, like when you have switched paths.
So when we would show 'path/subpath/subsubpath/file2', it might be a
completely different result than the local relative path with the same name.
>
> vs.
>
> svn -R pg svn:keywords path/subpath
>
> subpath/file1 - ...
> subpath/subsubpath/file2
> ...
And in this case we try to return the paths exactly in the form that you
used on the commandline, to allow you to match the result of multiple
arguments with multiple locations.
(Internally we convert to the absolute path and then back on output these
days, but we used to process everything in the original form before
Subversion 1.7)
If you don't pass something like @rev or -r REV (or a URL instead of a
path), this will always match your local files.
Note that in both cases we recommend using --xml if you are going to parse
the output via tools as that has a more stable output format in case we add
new features in new releases.
Bert
Received on 2016-11-16 15:52:11 CET