[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [RFC] New indented propget/proplist output needs a tweak for v1.6

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Wed, 21 Jan 2009 13:05:02 +0000

David Glasser wrote:
> One clarification: The old 'pg', with multiple targets or -R, was not
> actually machine-parsable, right?

Correct, and the new output is machine-parsable.

- Julian

> --dave
>
> On Tue, Jan 20, 2009 at 4:31 AM, Julian Foad <julianfoad_at_btopenworld.com> wrote:
> > I think I need to tweak the new indented "svn propget" output format.
> >
> >
> > BACKGROUND
> > ==========
> >
> > Some time back (r32484) I changed the output format of "svn proplist -v"
> > to indent every line of a multi-line property value, to make it
> > parseable and more readable:
> >
> > In v1.5:
> > [[[
> > $ svn-1.5.4 proplist -v subversion/tests/cmdline/
> > Properties on 'subversion/tests/cmdline':
> > svn:ignore : svn-test-work
> > httpd-*
> > .gdb_history
> > *.pyc
> > ...
> > ]]]
> >
> > In trunk:
> > [[[
> > $ svn proplist -v subversion/tests/cmdline/
> > Properties on 'subversion/tests/cmdline':
> > svn:ignore
> > svn-test-work
> > httpd-*
> > .gdb_history
> > *.pyc
> > ...
> > ]]]
> >
> > For "svn propget", I made a similar change, but a little differently. In
> > comparison to v1.5, the new format always shows the file name, always
> > shows the property name, and indents the value, but I chose to make this
> > new format happen only with "-v/--verbose", feeling that tools might be
> > more commonly parsing the output (at least when it is parseable, such as
> > when requesting just one property from one target). The command did not
> > use "-v" before.
> >
> > In v1.5, and also in trunk without "-v":
> > [[[
> > $ svn-1.5.4 propget svn:ignore subversion/tests/cmdline/
> > svn-test-work
> > httpd-*
> > .gdb_history
> > *.pyc
> > ...
> >
> > $ svn-1.5.4 propget -R svn:ignore subversion/tests/cmdline/
> > subversion/tests/cmdline/svntest - *.pyc
> > *.o
> > ...
> > subversion/tests/cmdline - svn-test-work
> > httpd-*
> > .gdb_history
> > *.pyc
> > ...
> > ]]]
> >
> > In trunk:
> > [[[
> > $ svn propget -v svn:ignore subversion/tests/cmdline/
> > Properties on 'subversion/tests/cmdline':
> > svn:ignore
> > svn-test-work
> > httpd-*
> > .gdb_history
> > *.pyc
> > ...
> >
> > $ svn propget -vR svn:ignore subversion/tests/cmdline/
> > Properties on 'subversion/tests/cmdline/svntest':
> > svn:ignore
> > *.pyc
> > *.o
> > ...
> > Properties on 'subversion/tests/cmdline':
> > svn:ignore
> > svn-test-work
> > httpd-*
> > .gdb_history
> > *.pyc
> > ...
> > ]]]
> >
> > The benefit is seen better with recursive or longer listings, especially
> > with long values like svn:mergeinfo and svn:ignore. (For properties with
> > short names and short single-line values, the old format looks nicer for
> > some purposes.)
> >
> >
> > NOW...
> > ======
> >
> > I don't like using "-v" to change propget's output format, and part of
> > the reason I left it like that is so we can get a feel for which we
> > prefer.
> >
> > I think we should:
> >
> > A. Make "propget" print just the plain value with no header when there
> > is only one target, like it used to, but use the new indented format
> > when there are multiple targets. Remove the new use of "-v". (Leave
> > "proplist" as it
> >
> > If you care, please have a look and a think. Alternatives are:
> >
> > B. Leave it as it is.
> >
> > C. Make "propget" use the new indented format always (like "proplist"
> > does), and so not add the use of the "--verbose" option in that command.
> >
> > D. Revert the change to "proplist" and go back to its old messy
> > output, for pure compatibility.
> >
> > I'll do (A) unless I hear a convincing argument to the contrary.
> >
> > - Julian
> >

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1041159
Received on 2009-01-21 14:06:24 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.