John,
Are you aware that this checking is only for the "svn propset" command? The
client is not going to refuse to accept an unknown property that the server
sends it during an update, for example, nor is it going to refuse to display
that property to the user, or anything else. Thus, if someone implements a
centralised configuration mechanism that puts properties with new names into
the tree, this old client will quite happily accept the new properties. The
only thing it will do is require confirmation (--force) if the user tries to
set such an unknown property by hand from the command line.
John Peacock wrote:
> Julian Foad wrote:
>
>> John Peacock wrote:
>>
>>> Just because the node props have a client-side effect[1] doesn't mean
>>> that there isn't a situation where being able to affect[1] them from
>>> the server is desireable.
>>
>> Please could you concoct an imaginary but realistic use case and
>> demonstrate how this proposal would adversely affect it? I still
>> can't see it.
>
> I wasn't thinking *specifically* of this proposal, but rather the
> "server resident project defaults" feature, which is largely covered by
> this issue:
>
> <http://subversion.tigris.org/issues/show_bug.cgi?id=1974>
As far as I am aware, the wish for "server-resident project defaults" is only a
wish, not a concrete proposal, so I have no idea whether it will even use
properties. Much less can I see how it might conflict with this checking of
their names, except to the extent that while configuring a project a user of an
old client might occasionally need to set some new properties that are
(presumably) solely for the benefit of newer clients.
> Suppose we add this feature now and then later implement a server config
> mechanism (possibly through inheritance). Future client code must now
> support both the hard-coded list, plus the server-pushed configurations,
No, a future client doesn't have to "support" this checking via a hard-coded
listed of property names. This checking is not a "feature", it's more like an
error or warning that only makes a difference to the user experience in (1)
erroneous use and (2) use of an old client to set a newly invented property.
It is not something that we have to "support". This checking could be removed
completely in a future client without breaking backward compatibility, and/or
it could be replaced with some other checking more appropriate to whatever new
property scheme is implemented.
> with the complication of precedence (client overrides server OR [...]
> Anytime the client contains a
> hard-coded list of acceptable values, it then becomes harder to support
> repository defaults.
I can only assume that you weren't aware of my first paragraph when you wrote
that. If you were, please elaborate as I don't understand.
> I have no problem with the *client* enforcing
> certain values; I just think the best way to store the list of legal
> values is on the *server*.
That's fine in principle. However, that's not a practical option now for
application at the point of executing a "svn propset" command on a local WC item.
Anyway, this proposal does not add a list of property names to the client. The
client already has the list of property names that it knows are legal today,
and the only assumption it is going to make about other names is that they are
either wrong or from the future, thus not likely to be set by hand very often.
Therefore (so I keep asserting) it is acceptable to require a special effort
from the user if he wants to set one that is unknown to the client.
>
> For an imaginary scenario, a project could decide that, for whatever
> reason, they want to forbid certain otherwise legal svn:* properties
> (say svn:eol-style because they discover that it has been used in the
> project incorrectly in the past). With a hard-coded list in place on
> the client, it becomes much more complicated to support that.
I can't see how it becomes any more complicated that it would be without this
currently proposed checking in place. The project administrators would have to
find some place and means to perform their additional check. The check added
by the current proposal would simply become redundant, always letting
"svn:eol-style" through at its stage. That's simple and logical, isn't it? We
never refrain from basic validation just because people might want additional
restrictions. We forbid adding a directory called ".svn" even though the
project administrator might want to forbid other pathnames as well.
>
> It's not that big a deal. I'm just trying to look at the long view and
> how this [admittedly useful] feature might interact with other features
> not yet complete.
Thanks for looking ahead like this. Please do continue if you still have
concerns or if I have misunderstood you.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 2 19:05:40 2005