Re: svn --recursive and externals
Stefan Sperling wrote: >On Wed, Nov 16, 2016 at 02:22:53PM +, Lorenz wrote: >> looks like "svn --recursive ..." ignors externals. >> >> Is this intended? > >Look for --ignore-externals or --include-externals options in the >output of 'svn help SUBCOMMAND', where SUBCOMMAND is whichever >svn command you're trying to use. > >Some subcommands recurse into externals by default, and some don't. >The decision about which should be the default usually involves tradeoffs >between several use cases so there is no single rule for this. > >> I don't seem to be able to find any documentation about the it. >> Either there is none, or my seach skills are lacking badly. > >There is some information in the book about this at >http://svnbook.red-bean.com/nightly/en/svn.advanced.externals.html > >And of course in 'svn help'. Ah well, 'svn help list' shows '--include-externals' as an option, but thats the only hint it does not recurse into externals by default. 'svn help pg' on the other hand doen't gives not infomation about externals at all, and it rejects '--include-externals'. So no recursing into externals with 'svn propget' at all 8-( -- 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: svn --recursive and externals
On Wed, Nov 16, 2016 at 02:22:53PM +, Lorenz wrote: > Hi all, > > looks like "svn --recursive ..." ignors externals. > > Is this intended? Look for --ignore-externals or --include-externals options in the output of 'svn help SUBCOMMAND', where SUBCOMMAND is whichever svn command you're trying to use. Some subcommands recurse into externals by default, and some don't. The decision about which should be the default usually involves tradeoffs between several use cases so there is no single rule for this. > I don't seem to be able to find any documentation about the it. > Either there is none, or my seach skills are lacking badly. There is some information in the book about this at http://svnbook.red-bean.com/nightly/en/svn.advanced.externals.html And of course in 'svn help'.
svn --recursive and externals
Hi all, looks like "svn --recursive ..." ignors externals. Is this intended? I don't seem to be able to find any documentation about the it. Either there is none, or my seach skills are lacking badly. -- Lorenz
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
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 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? 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
