svn info --detail [was: Time to branch 1.9]
From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Mon, 16 Feb 2015 11:07:55 +0000
Branko Čibej wrote:
+1 to that.
For easier visibility, here's a copy of the BRANCH-README:
[[[
Instead of 'svn youngest', we'll implement an extension to 'svn info',
- Add a --detail=FIELD option to 'svn info' that will cause it to
$ svn info ^/subversion/trunk --detail=revision 1660035
and so on.
- The --detail option is incompatible with the --xml option
- Initially, only a few field values will be supported with
- The 'svn youngest' command will be removed.
Hooray, more command-line UI designing.
I'm not going to bikeshed about the option name, but how should we choose the spelling of the option values (like "=last-changed-rev")?
* Match the keys of the plain "svn info" output?
* Match the XML element/attribute names?
* Choose the argument values independently of existing (XML and plain) outputs?
If we match the keys of the plain "svn info" output, would that be in the current locale or the C locale or both, and with spaces (optionally?) translated to "-"? Lower case?
--detail=revision -> 123
The XML element/attribute names are locale-independent, which is good for scripting, and simple to implement. On the down side, they are nested: <entry revision="123">...<commit revision="456"><author>me</author></commit></entry>, so we might have (always within an <entry>)
--detail=#revision -> 123
Or simplify the syntax to use "-" always as the separator between elements and/or attributes, assuming we won't have any that clash:
--detail=revision -> 123
Choosing an independent set of fixed identifiers is in some ways the easiest approach, but is that just because it requires the least thought at the design stage? We'd make them non-localized, for scripting purposes, I assume?
- Julian
|
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.