[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: r1592724: In 'svn propget --revprop', error out on non-existing properties.

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Mon, 19 May 2014 17:37:12 +0100 (BST)

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.
Received on 2014-05-19 18:40:38 CEST

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.