[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: [RFC] svn propset should require 'force' to set unknown svn: propnames

From: Bert Huijben <bert_at_qqmail.nl>
Date: Tue, 27 Nov 2012 09:11:32 +0000

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)


 *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:

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?


On Sun, Nov 18, 2012 at 9:50 PM, Julian Foad <julianfoad_at_btopenworld.com>
> '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!
> Certified & Supported Apache Subversion Downloads:
Received on 2012-11-27 10:12:06 CET

This is an archived mail posted to the Subversion Dev mailing list.