John Peacock wrote:
>
> AFAIK, the client contains the list of property names now only because
> it needs to use them locally. It is not used as data validation
> currently; the client gets the current list solely by having included
> the appropriate .h file which is shared by client and server code.
Yes, I agree with that. However, I think the fact that it needs to use the
properties is relevant. So far, there are no properties that the client
doesn't have any reason to be aware of.
> My example specifically chose to limit the use of a current property to
> make the point that the repository admin might want to require special
> effort for even "normal" attributes. This wouldn't have any bearing on
> the existing functionality that *uses* those properties. It would just
> make the data validation something that could be modified without
> installing a new client.
I can see how that would be a useful _additional_ validation or restriction. I
can't see how it is an argument against the fixed validation provided by this
proposal. Certainly if there were an alternative patch which did enable an
administrator to configure the set of allowed properties, it might be superior,
but there isn't.
Let me try a side-by-side comparison of the status quo and the proposed patch
in use cases that hopefully include the ones that concern you. Of course I may
be biased.
For these use cases, let's say that log message templates are implemented in
the future as a purely client-side feature that can be activated by setting
"svn:log-template" on a directory from which commits are expected to be made.
"svn propset svn:eol-style native readme.txt"
Status quo: fine
Patched: fine
"svn propset svn:ignores *.obj ."
Status quo: allows it (oops)
Patched: "error: unrecognised property" (thanks)
A user wanting the new log template feature, using a client that doesn't yet
know about it:
"svn propset svn:log-template -F template.txt ."
Status quo: allows it (good)
Patched: "error: unrecognised property" (oh, thanks, I need to upgrade)
A user wanting the new log template feature, using a new client that does know
about it:
"svn propset svn:log-template -F template.txt ."
Status quo: allows it (good)
Patched: allows it (good)
A user configuring the new log template feature for those of his colleagues who
have new clients, using a client that doesn't yet know about it, and he hasn't
yet learned that he needs to use "--force":
"svn propset svn:log-template -F template.txt ."
Status quo: allows it (good)
Patched: "error: unrecognised property" (oh, I'll use "--force")
Administrator wants to forbid use of "svn:eol-style" in his project.
Status quo: can only be enforced at commit time by hooks
Patched: can only be enforced at commit time by hooks
Are there any conceivable cases that you would like to add?
Here's another opportunity for clarification. By now I have forgotten all
implementation details of the patch that was submitted. When I said it "only
applies to svn propset" I didn't make it clear whether it would be in the
public svn_client_propset2() which is used by all clients, or in the
command-line client's svn_cl__propset(). The former does the existing checks.
If we were to add the new checks into the library, then a third-party client
such as TortoiseSVN might be stuck using those old checks for a while after we
have introduced a new property name into the system. The less controversial
option would be to put these new checks in the command-line client, because
that would guarantee that a new version of the only client that performs the
checks would be available at the same time as the new property is introduced.
Would that be more acceptable to 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 20:23:09 2005