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
