'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

Reply via email to