Branko Čibej wrote:
> On 25.11.2012 23:30, Julian Foad wrote:
>> To answer the question I think you meant: requiring force for
>> setting svn:mergeinfo is a separate issue and shouldn't necessarily
>> work the same way or produce the same error message as the unknown
>> propname check. Personally, I have not been feeling that we need
>> to do it, though I am willing to be persuaded otherwise. If we do,
>> we would probably want to include 'propdel' as well as propset and
>> propedit.
>
> Well, svn:mergeinfo is special in the sense that changing it can
> cause wrong results later on. None of the others have as far-reaching
> consequences.
>
> So what I'm really asking is if we can risk ever suggesting
> "svn:mergeinfo" as the correct spelling of a mistyped property name.
Certainly we can and should suggest 'svn:mergeinfo' if the user typed
'svn:mergefino' or 'svn:ergeinfo' or 'svn:merginfo' or 'svn:mergeinfoo' or
'snv:mergeinfo'. Zero risk.
> Which I agree is orthogonal to the question of whether we should
> always require --force for anything pertaining to svn:mergeinfo,
> but is relevant to my original question in the sense that we may
> not want it to be a "user-visible and -settable versioned node
> property".
>> That last point makes me wonder: should this 'unknown prop name'
>> check also apply to 'propdel'? My proposal argued not, but now I'm
>> reconsidering. My arguments were (1) We intentionally don't check
>> or care if deleting a prop with a bad value, and (2) we don't have
>> a '--force' option on 'propdel' already. But (1) is not really
>> analogous to deleting a prop with an unrecognized name, and (2) is
>> weak. Now I'm leaning towards making 'propdel' consistent with
>> 'propset', because removing a property such as mime-type or
>> eol-style is semantically quite similar to adding or changing the
>> property. I imagine more annoyance results from mis-spelling a
>> propdel propname than would result from having to specify '--force'
>> to delete some svn: propname that the client doesn't know about.
>
> Possibly. Setting an unknown prop name causes nothing to happen
> silently; whereas deleting it may cause something unexpected to happen,
> also silently.
I don't understand why you say that.
In general, setting *or* deleting an unknown prop name causes nothing
significant to happen on *this* client, and may cause something (expected or
unexpected) to happen on another client. More specifically, we can talk about
two classes of property names that are unknown to this client: those unknown to
any client and those known to some other clients (such as a future 'svn' client
or a non-svn client). The effect, if we don't catch it, can be summarized as:
Example This client Other client
------------------- ----------- ------------
pset svn:mergefino [1] { Fails to have the expected effect }
pdel svn:mergefino [1] { Error 'nonexistent...' [3], and
fails to have the expected effect }
pset svn:mergeinfo2 [2] No-op SOME EFFECT
pdel svn:mergeinfo2 [2] No-op SOME EFFECT
(and error?[3])
[1] Typo -- prop name unknown to any client.
[2] Prop name known to some other clients (let's pretend).
[3] Depends whether the prop already exists.
If the prop name is unknown to any client, it's almost certainly a typo and
should be diagnosed as such, no matter whether setting or deleting. The prop
almost certainly isn't already set; if it is then the user has probably set it
by accident (or discovered that somebody else did) and is now running
'svn:propdel' to delete it. If we don't diagnose it, the inconvenience for the
user is greater for 'propset' (where svn 1.7 proceeds without complaint) and
less for 'propdel' (where svn 1.7 already complains 'Attempting to delete
nonexistent property ...').
If the prop name is known to other clients, setting and deleting are equally
significant as far as this client can tell: either of them can cause some
effect on another client that is unexpected (or quite possibly expected and
intended) by this user.
It's probably fair to assume that the 'typo -- unknown to any client' scenario
is common and the 'known to other clients' scenario uncommon in practice.
My conclusion is flagging 'propdel' is less important than flagging 'propset'
but still useful, but not enough to make a fuss about. Oops, too late, I'va
already made a fuss about it.
- Julian
