On 25.11.2012 23:30, Julian Foad wrote:
> 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.
Well, svn:mergeinfo is special in the sense that changing it can cause
wrong results later on. None of the others have as far-reaching
consequences.
So what I'm really asking is if we can risk ever suggesting
"svn:mergeinfo" as the correct spelling of a mistyped property name.
Which I agree is orthogonal to the question of whether we should always
require --force for anything pertaining to svn:mergeinfo, but is
relevant to my original question in the sense that we may not want it to
be a "user-visible and -settable versioned node property".
§
> 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.
Possibly. Setting an unknown prop name causes nothing to happen
silently; whereas deleting it may cause something unexpected to happen,
also silently.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Received on 2012-11-26 03:09:53 CET