--strict vs --no-newline
From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Mon, 9 Jun 2014 17:39:10 +0100 (BST)
Summary: I noticed in irregularity, and I plan to tweak the command-line UI a bit to make the '--no-newline' and '--strict' options more consistent.
For a long time we had:
* svnversion --no-newline
* svn propget --strict
Originally, 'svn propget --strict' also suppressed the printing of the file name, hence its name being rather general, but in recent years the option is not allowed where more than one result is possible (multiple targets, or depth > empty) nor with --verbose.
With the new-in-1.8(?) '--show-inherited-props' option, 'svn propget --strict' will suppress the newline and the printing of the filename when printing the (multiple) inherited properties for a single target path. That means the property values are all squashed together, and this seems to be a non-useful behaviour, an oversight. I think it should reject the '--strict' option when showing inherited properties, like for the other cases that can produce multiple outputs.
More recently, we gained an 'svn youngest' command, which takes a '--no-newline' option. In r1601362 today, I added the '--no-newline' to 'svnlook youngest', for consistency with the new 'svn youngest'.
Now I intend to:
* make 'svn propget --strict --show-inherited-props' error out;
* make 'svn propget --no-newline' an alias for 'svn propget --strict'.
How to do the latter, exactly? Either make '--strict' an option-name alias for '--no-newline', in which case 'svn youngest --strict' will become an available option; or keep the two options separate and have 'propget' accept both (with the same behaviour) and 'youngest' only accept '--no-newline'. Which is the cleaner UI, the one with fewer invocation options for the user or the one with fewer irregularities?
Thoughts?
- Julian
-- Join WANdisco's free daily demo sessions on Scaling Subversion for the Enterprise <http://www.wandisco.com/training/webinars>Received on 2014-06-09 18:42:24 CEST |
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.