Eh? So it already has a separate/different semantic? Yay. On Nov 27, 2012 4:11 AM, "Bert Huijben" <b...@qqmail.nl> wrote:
> In this case I think the answer is easier than in most similar cases: We > already support --force on propset in older Subversion versions. > > (At least that is why I didn’t ask that specific question) > > Bert > > *From:* Greg Stein <gst...@gmail.com> > *Sent:* November 27, 2012 9:11 AM > *To:* Julian Foad <julianf...@btopenworld.com>,Branko Čibej > *CC:* Subversion Development <dev@subversion.apache.org> > *Subject:* Re: [RFC] svn propset should require 'force' to set unknown > svn: propnames > > Brane has done some excellent work here. But it seems nobody has asked > the question: why --force instead of (say) --allow-propname ? > > Haven't we already decided that --force is horribly overloaded, and > horribly undefined? > > Thx, > -g > > On Sun, Nov 18, 2012 at 9:50 PM, Julian Foad <julianf...@btopenworld.com> > wrote: > > 'svn propset' lets us create any property name 'svn:foo', with good > reason: we want old clients to be able to set and edit properties that only > the newer clients know about. However, there is a pitfall for unwary > users: it's east to mis-spell a prop name and not notice. For example: > > > > svn:ignores > > svn:global-ignore > > > > are both mis-spellings. > > > > It would seem reasonable to require '--force' to set an unknown 'svn:' > property name. Note that we already require '--force' to set a known > svn:something property to an invalid value. > > > > Proposal: > > > > For any unrecognized property name in the 'svn:' name space, these would > bail out with an error unless '--force' is given: > > > > svn pset svn:foo > > svn pedit svn:foo > > > > and all other subcommands where properties are handled would continue to > work as normal, no '--force' needed, including: > > > > svn pdel svn:foo > > svn pget svn:foo > > svn plist > > svn patch, merge, diff, checkout, update, switch, ... > > > > Rationale notes: > > > > 'propset' would bail out even if the property already exists. One > reason for this is so that multi-target or 'recursive' mode doesn't have to > do anything special if the property exists on only some of the targets. > > > > 'pset' is the only one that really needs 'force' to meet the needs of > this proposal. If a property already exists then it's probably best to > assume that it exists on purpose, so we could argue that there is little > harm in allowing 'pedit' and 'pdel'. Currently, 'pset' and 'pedit' require > '--force' to set an invalid *value* for a known property (such as 'svn pset > svn:eol-style x'); pdel doesn't take a '--force' option and intentionally > allows properties with invalid values to be deleted. An advantage in > discouraging 'svn pedit svn:foo' is that it can't validate the value if it > doesn't know anything about 'svn:foo'. For these reasons and for > consistency with the value-checking, the proposal has both 'pset' and > 'pedit' validate the name, but not 'pdel'. > > > > > > Thoughts, objections? > > > > - Julian > > > > > > > > -- > > Subversion Live 2012 - 2 Days: training, networking, demos & more! > http://bit.ly/NgUaRi > > Certified & Supported Apache Subversion Downloads: > http://www.wandisco.com/subversion/download > > >