Re: multiple targets for 'svnlook propget'
From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Fri, 16 Nov 2012 15:58:40 +0000 (GMT)
-- Subversion Live 2012 - 2 Days: training, networking, demos & more! http://bit.ly/NgUaRi Certified & Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download ----- Original Message ----- > From: Johan Corveleyn <jcorvel_at_gmail.com> > To: Julian Foad <julianfoad_at_btopenworld.com> > Cc: Subversion Development <dev_at_subversion.apache.org> > Sent: Friday, 16 November 2012, 8:54 > Subject: Re: multiple targets for 'svnlook propget' > > On Fri, Nov 16, 2012 at 1:19 PM, Julian Foad <julianfoad_at_btopenworld.com> > wrote: >> Johan Corveleyn wrote: >> >>> Right now, 'svnlook propget' supports only a single > PATH_IN_REPOS >>> argument: >>> >>> usage: 1. svnlook propget REPOS_PATH PROPNAME PATH_IN_REPOS >>> >>> I think it would be useful to support multiple targets, like 'svn >>> propget'. That would make it much faster to gather all props set >>> during a transaction, for instance in a pre-commit hook: >>> >>> svnlook propget -t $TXN $REPOS svn:eol-style `svnlook changed -t >>> $TXN $REPOS` >>> >>> The only complication I see, is that the output for multiple targets >>> has to write the node for which the properties are shown. >>> >>> Looking at 'svn propget' for inspiration, we see that it > doesn't >>> output the node when there is only one target. But it does when there >>> are multiple targets. I guess 'svnlook propget' could implement > the >>> same behavior, which means that the output for single target remains >>> backwards compatible (at the cost of slight increase of complexity for >>> scripts that parse that output -> they have to know if they passed > one >>> or mutiple targets). >>> >>> Current output of 'svn propget': >>> >>> $ svn pg svn:eol-style ^/file.txt >>> native >>> $ svn pg svn:eol-style ^/file.txt ^/binary.exe ^/file2.txt >>> http://my.svn.server/svn/file.txt - native >>> http://my.svn.server/svn/file2.txt - native >>> >>> (As you can see, the it simply does not output the targets that > don't >>> have the property, and shows the actual target for every file that >>> does) >>> >>> Or with working copy targets: >>> >>> $ svn pg svn:eol-style file.txt binary.exe file2.txt >>> file.txt - native >>> file2.txt - native >>> >>> >>> Now, when we look at the output of 'svnlook propget': >>> >>> $ svnlook pg repos svn:eol-style file.txt >>> native >>> >>> We could have following multi-target output: >>> >>> $ svnlook pg repos svn:eol-style file.txt binary.exe file2.txt >>> file.txt - native >>> file2.txt - native >>> >>> >>> Thoughts? >>> >>> >>> P.S.: This multi-target output isn't very parseable for multi-line >>> properties. Currently, 'svn propget' also has this problem, but > users >>> can use --xml to get machine-readable output. >> >> I added a "svn propget --verbose" mode (in 1.7 I think) to > resolve that problem. It uses the same format as "svn proplist > --verbose", which is like this: >> >> [[[ >> $ svn pg -vR svn:ignore # selected bits of output are shown >> Properties on 'subversion/bindings/ctypes-python/csvn/ext': >> svn:ignore >> *.pyc >> Properties on 'subversion/mod_dav_svn/reports': >> svn:ignore >> .libs >> >> Properties on 'contrib/server-side/svnstsw/include': >> svn:ignore >> Makefile >> Makefile.in >> >> ]]] >> >> If the email system hasn't mangled the white space, you should be able > to see that the prop name is indented by two spaces and the value by four > spaces, and newlines in the value are preserved (with exactly one LF added to > ensure there is a line break in the output) so it's fully parseable. >> >>> Maybe 'svnlook propget' >>> should eventually also grow a --xml option to handle this. But I'd > say >>> that's yet another feature. For now, I would be happy if svnlook > could >>> already do "plain" output for multiple targets, which can > already be >>> useful/parseable for single-line properties like svn:eol-style. >> >> Given that 'svnlook' is very much expected to be used by scripts > ('svn' serves most human-interaction cases), I don't see > implementing the "plain" output is a good idea. >> >> But +1 on implementing the "svn pg -v" format. > > Ok, but then you probably mean that I should add two things: > 1) Add multi-target support to 'svnlook pg' > 2) Add -v to 'svnlook pg', format like 'svn pg -v' > > The combination of 1 and 2 would then give us a parseable output for > multiple targets. > > But I guess I shouldn't forbid the use of 1 without 2, right? I think > it would be strange to say "cannot use multiple arguments without > --verbose" ... > So it seems I should also provide a format for the multi-arg case > without -v ... like the current format of 'svn pg' without -v. > > > I also note that the same enhancement can't easily be made for > proplist. Mainly because 'svnlook pl' already has a --verbose option, > so we can't change the output of 'svnlook pl --verbose' with a > single > target without breaking backwards compatibility. > > - 'svn pl' always shows "Properties on 'XXX':" > (whether for single > target or multiple targets, whether verbose or not) > - 'svnlook pl' does not, and when used with --verbose it doesn't > indent multiline properties like 'svn pl' does. > > [[[ > $ svn pl sources --verbose > Properties on 'sources': > svn:ignore > .classpath > .settings > .project > > $ svnlook pl repos trunk/sources --verbose > svn:ignore : .classpath > .settings > .project > ]]] > > Currently I'm mainly focused on propget, so proplist doesn't bother me > too much. But it would of course be even better if proplist behavior > would match the propget behavior. If anyone has any ideas for this ... It seems to me that the 'svnlook pl --verbose' output is pretty useless. Well, OK, not useless, but poor. IIRC 'svn pl --verbose' was like that and I changed it to use the new format, at the same time as I changed 'svn pg --verbose' to use the new format. In terms of back-compat, however, 'svn pl --verbose' didn't exist before I added it, whereas I changed the output of 'svn pl --verbose' in an incompatible way. I simply decided that the latter was an acceptable change. Apart from backward compatibility concerns, I would totally go for making 'svn pg' and 'svn pl' and 'svnlook pg' and 'svnlook pl' all use the indented & parseable format, and not relate it to the '--verbose' option at all. I dunno, add a '--parseable' (or should that be '--parsable') option to select the new format? - JulianReceived on 2012-11-16 16:59:18 CET |
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.