> -----Original Message-----
> From: Branko Čibej [mailto:br...@wandisco.com]
> Sent: dinsdag 17 februari 2015 10:51
> To: dev@subversion.apache.org
> Subject: Re: svn info --detail [was: Time to branch 1.9]
>
> On 17.02.2015 10:29, Julian Foad wrote:
> > Ben Reser wrote:
> >> On 2/16/15 3:57 AM, Branko Čibej wrote:
> >>> At first I thought I'd just lowercase the untranslated keys that 'svn
> >>> info' displays, replacing spaces with dashes. But there's a strong case
> >>> for using the same names as the --xml output; not because it's easier to
> >>> implement, but because it's at least marginally consistent with
> >>> something we already have.
> >> The XML names are pretty bad in my opinion. These are the two blocks out
> of
> >> the XML output that have the current revision and the last changed revision
> >> respectively:
> > I don't necessarily disagree with your conclusion, but want to correct the
> facts.
> >
> >> [[[
> >> <entry
> >> kind="file"
> >> path="install.sh"
> >> revision="148">
> >> <commit
> >> revision="35">
> > ... </commit>
> > ... </entry>
> >
> >> ]]]
> >>
> >> I think command line users are going to find the distinction between
> >> "entry-revision" and "commit-revision" to be obscure.
> > In our XML output, the <entry> element is the wrapper for the whole of the
> info for one target, and is thus redundant in these specifications. These two
> would be "revision" and "commit-revision".
> >
> >> Entry is leakage from our WC data model leaking into the XML output,
> where it
> >> really doesn't belong.
> > I don't think it is: rather, it is just saying in the most general sense
> > that this is
> one entry in a list. Compare the other XML outputs (most easily seen by
> examining subversion/svn/schema/*.rnc) where "entry" is used for the element
> of various kinds of lists -- lines of blame, targets of status, etc.
> >
> >> The XML values taken literally would also be way more verbose than
> necessary.
> >> "entry-path" versus just "path".
> > This one would be just "path".
> >
> >> For that matter are you going to keep some of the parent blocks like "wc-
> info"
> >> which would make things like "schedule" into "wc-info-schedule"
> >>
> >> The repository root key would end up being "entry-repository-root" if you
> kept
> >> the nesting as well.
> > Just "repository-root".
> >
> >> So in my opinion just using the untranslated info keys with spaces turned
> >> into
> >> "-" is far better.
> >>
> >> You're almost certainly going to end up making arbitrary decisions anyway
> since
> >> some of the names start getting silly.
>
> For now, I'd only expose the attributes of <entry> and <commit> and the
> elements within <commit> and <repository>, along with the URLs. The
> definitive list is:
>
> revision
> kind
> url
> relative-url
> repository-root
> repository-uuid
> commit-revision
> commit-author
> commit-date
>
> I wouldn't expose entry's 'path' attribute because it doesn't make much
> sense; in the WC case, it's already known and in the URL case, it's
> always the basename, which is also known. I'd also leave wc-info,
> conflicts etc. out for now.
>
>
> All that said: Johan makes a good point about using keywords that are
> more likely to be familiar to users; the XML-based ones are far from that.
I paint my shed in the 'last-revision', 'last-author' and 'last-date' color...
(Following Johan's suggestion and all recent code in libsvn_wc)
Bert
