[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: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Sat, 24 Nov 2012 16:20:41 +0200

Branko Čibej wrote on Sat, Nov 24, 2012 at 13:38:39 +0100:
> On 24.11.2012 13:30, Daniel Shahaf wrote:
> > Branko Čibej wrote on Sat, Nov 24, 2012 at 12:33:01 +0100:
> >> I'm also considering requiring --force if one tries to use a revision
> >> property name as a node property, and vice versa.
> >>
> > +0
> >
> >> $ svn ps svn:barfoo x .
> >> svn: E195011: 'svn:barfoo' is not a valid svn: property name; did you mean 'svn:group'?
> >> (To set the 'svn:barfoo' property, re-run with '--force'.)
> >>
> >> In this case the suggestion is clearly bogus.
> > It seems the code should filter svn:user and svn:group from
> > SVN_PROP_ALL_NODE_PROPS?
>
> That wouldn't make suggestion any less silly. :)
>

That would make the suggestion of 'svn:group' not happen at all.

> In fact, with the change I made just now (to not consider the prefix
> when sorting the properties by similarity), trying to set "svn:barfoo"
> results in the suggestion to use "svn:mergeinfo" instead, which is just
> as wrong.
>

Maybe it shouldn't suggest anything? IIRC the code just does a qsort()
and suggests the first option --- it doesn't check that the similarity
score of that option exceeds some minimum threshold.

> Regarding svn:group, svn:user and svn:unix-mode, these are defined in
> svn_props.h as reserved, user-visible properties and I see no reason to
> require --force to set them on /this/ level. This is purely a syntactic
> filter; it would be wrong IMO to infuse any kind of awareness of
> semantics into it.
>

I could go either way about whether it should ever suggest
'svn:mergeinfo'.

> -- Brane
>
> --
> Branko Čibej
> Director of Subversion | WANdisco | www.wandisco.com
>
Received on 2012-11-24 15:21:22 CET

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.