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.
- Julian
Received on 2012-11-16 13:19:55 CET