Eh? So it already has a separate/different semantic?
Yay.
On Nov 27, 2012 4:11 AM, "Bert Huijben" <bert_at_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 <gstein_at_gmail.com>
> *Sent:* November 27, 2012 9:11 AM
> *To:* Julian Foad <julianfoad_at_btopenworld.com>,Branko Čibej
> *CC:* Subversion Development <dev_at_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 <julianfoad_at_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
> >
>
Received on 2012-11-27 11:33:19 CET