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
