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.
-- Brane
Received on 2015-02-17 10:52:42 CET