Re: discrepancies between 'svn -R list' and 'svn -R propget' (on windows using TSVN build command line client)
Bert Huijben wrote: >> -Original Message- >> From: Lorenz [mailto:loren...@yahoo.com] >> Sent: woensdag 16 november 2016 15:02 >> To: users@subversion.apache.org >> Subject: Re: discrepancies between 'svn -R list' and 'svn -R propget' (on >> windows using TSVN build command line client) >>[...] >> 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. after some more experimenting it looks to me that: 'svn list' always returns paths relative to the given folder, independent if its given as a local path or as an URL. That even makes sense 8-) because it's always the repositry contents that is listed (as 'svn help list' tells in the first sentence) That also means 'svn list' won't show locally added files, but still list locally deleted files. 'svn propget' on the other hand returns paths relative to the CWD in case of a local path, or in case of an URL the complete URL. And it's showing local information in case of a local path, but repository information in case of an URL. I think 'svn help propget/list' should make that clear. All in all, there goes my idea of how to determine files missing certain properties. I'll open a new thread for that then. -- Lorenz
RE: discrepancies between 'svn -R list' and 'svn -R propget' (on windows using TSVN build command line client)
> -Original Message- > From: Lorenz [mailto:loren...@yahoo.com] > Sent: woensdag 16 november 2016 15:02 > To: users@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
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 ... vs. svn -R pg svn:keywords path/subpath subpath/file1 - ... subpath/subsubpath/file2 ... -- Lorenz
RE: discrepancies between 'svn -R list' and 'svn -R propget' (on windows using TSVN build command line client)
> -Original Message- > From: Lorenz [mailto:loren...@yahoo.com] > Sent: woensdag 16 november 2016 10:02 > To: users@subversion.apache.org > Subject: discrepancies between 'svn -R list' and 'svn -R propget' (on windows > using TSVN build command line client) > > Hi all, > > navigating to a working copy folder (or a subfolder thereof) and > issuing 'svn -R list path/sub' or 'svn -R list path\sub' results in: > > file1 > subsub/file2 > ... > > > whereas 'svn -R pg svn:keywords path/sub' > or 'svn -R pg svn:keywords path\sub' results in: > > sub\file1 - Id URL > sub\subsub\file2 - Id URL > ... > > > There are two discrepancies the first of which looks like it is not > windos depended: > > 'svn propget' always lists the 'sub' part of the path, > 'svn list' does not. > > is this the same under linux, and if so is it intended behaviour? 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. > The second one is windows dependent (maybe even TSVN specific): > > 'svn list' uses '/' whereas 'svn pg' uses '\' > > do all native windows clients behave this way or is this with the TSVN > client only? The standard 'svn' clients will all use the same formatting as they share the same code here. (TortoiseSVN compiles the standard 'svn' sourcecode for their svn binary) The formatting is really part of the client as internally Subversion always uses '/', so any other client than 'svn' may use different formatting, but I think you can expect 'svn' to keep using the existing formats. Bert > > > I'm on win7 using the command line client that ships with tortoise svn > (TSVN 1.9.4 linked against svn 1.9.4) > -- > > Lorenz
