Branko Čibej wrote on Tue, Nov 27, 2018 at 14:49:59 +0100:
> On second thought, I think I should revert this. Consider the
> inconsistency with --show-item=last-changed-date:
>
> $ svn info ^/subversion/trunk/CHANGES --human-readable --show-item=last-changed-date
> 2018-11-26T02:50:47.513639Z
>
> but
>
> $ svn info ^/subversion/trunk/CHANGES | grep '^Last Changed Date'
> Last Changed Date: 2018-11-26 03:50:47 +0100 (Mon, 26 Nov 2018)
>
>
> The output from --show-item was always meant to be strictly for scripts.
That's an interesting one. I never realized that --show-item formats
the output differently; I assumed it was designed to simply save scripts
having to do the
.
LC_ALL=C svn info "$@" | sed -ne 's/^Last Changed Date: //p'
.
dance, without requiring any other changes on scripts' side.
So on the one hand, I understand your argument: proliferation of output
formats is bad, and we don't want to have four or five different date
formats ('svn info', 'svn info --show-item', 'svn info --xml', and
'--human-readable' versions of the first two).
On the other hand, I don't quite understand your argument: I don't
understand why "The output from --show-item was always meant to be
strictly for scripts" is an argument against "'svn info --show-item'
should format the output differently if a new opt-in option flag,
--human-readable, is passed". Adding that flag is fully backwards
compatible with existing scripts that use --show-item. In your example,
«svn info --show-item=last-changed-date» could continue to emit the raw
ISO8601 form, as it does now, and if --human-readable is passed it could
emit some other format.
All that said, if you feel it's better to remove -H from 'info' for now,
then sure. We can always add it in a later release.
Cheers,
Daniel
Received on 2018-11-28 16:10:40 CET