Re: [RFC] svn propset should require 'force' to set unknown svn: propnames

Branko Čibej wrote:

> The latest change takes account of property name similarity. So for example,
>
>     svn propset svn:foobar .
>
> will emit an error but will not suggest an alternative spelling, whereas
>
>     svn propset svn:ignores .
>
> will suggest two, svn:ignore and svn:global-ignores.
>
> The only open question now, IMO, is whether I should remove
> svn:mergeinfo from SVN_PROP_NODE_ALL_PROPS defined in
> svn_prop.h. I'm leaning towards "yes" but would like to hear
> opinions from the merge(info) experts.

EDOMAIN: question containing symbol 'SVN_PROP_NODE_ALL_PROPS' is not formulated in the problem domain.

/**
 * This is a list of all user-vixible and -settable versioned node properties.
 *
 * @since New in 1.8
 */
#define SVN_PROP_NODE_ALL_PROPS SVN_PROP_MIME_TYPE, ...

To answer the question I think you meant: requiring force for setting svn:mergeinfo is a separate issue and shouldn't necessarily work the same way or produce the same error message as the unknown propname check.  Personally, I have not been feeling that we need to do it, though I am willing to be persuaded otherwise.  If we do, we would probably want to include 'propdel' as well as propset and propedit.

That last point makes me wonder: should this 'unknown prop name' check also apply to 'propdel'?  My proposal argued not, but now I'm reconsidering.  My arguments were (1) We intentionally don't check or care if deleting a prop with a bad value, and (2) we don't have a '--force' option on 'propdel' already.  But (1) is not really analogous to deleting a prop with an unrecognized name, and (2) is weak.  Now I'm leaning towards making 'propdel' consistent with 'propset', because removing a property such as mime-type or eol-style is semantically quite similar to adding or changing the property.  I imagine more annoyance results from mis-spelling a propdel propname than would result from having to specify '--force' to delete some svn: propname that the client doesn't know about.

- Julian
Received on 2012-11-25 23:30:37 CET