subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Foad <julianf...@btopenworld.com>
Subject Re: r1592724: In 'svn propget --revprop', error out on non-existing properties.
Date Mon, 19 May 2014 16:37:12 GMT
Daniel Shahaf wrote:
> Julian Foad wrote on Mon, May 19, 2014 at 12:15:00 +0100:
>> Hi Daniel. Can I ask: Why?
> 
> Because I assumed it would error, realized it didn't, and digging into
> the history revealed that it was probably an unintentional omission.

OK. I recall we made a similar change -- to 'propdel' I think -- a couple of releases ago,
maybe 1.7.

>> This makes 'propget --revprop' inconsistent with 'propget [versioned
>> prop]' which still prints nothing. Did you intend to change both
>> forms, for consistency with 'svnlook'?
> 
> I hadn't checked 'svn propget versioned_prop'.  It makes
> sense to me that it should error out on non-existing properties.

Me too, but ...

> Would that be a reasonable course to take?  Or does anyone prefer to
> retain the pre-r1592724 behaviour?

While I prefer your version as a better UI design, I think this particular change is one that
might be better reverted, as the benefit of leaving the UI as it was might outweigh the benefit
of changing it. I have in mind that some third parties do treat our CLI as an API, whatever
we think of the rights and wrongs of that. For example, NetBeans IDE version 7 can use Subversion
1.8 *only* through the command-line client CLI [1].

The difficulty is I can't make an informed evaluation of the pros and cons by considering
this change alone. The user experience may improve incrementally with each tweak we make [2],
but if the first incompatible change breaks NetBeans's Subversion support (for example), the
impact doesn't get much worse if we make lots more incompatible changes after that. Making
one such change alone might therefore be a net loss, whereas making that same change as part
of a larger set of changes might be a good thing.

Either we should batch up the proposed UI changes and consider as a whole whether they're
worth making for the next release, or we should err on the side of caution and avoid making
any change where the potential benefit is small and the potential for harm through incompatibility
is significant. I might email separately about the idea of batching them up.

- Julian


[1] For other version combinations it can interface through JavaHL or SvnKit.

[2] At least for new users and adaptable users; ignoring habituation.


Mime
View raw message