On Fri, Aug 17, 2012 at 12:11 PM, Greg Hudson <ghud...@mit.edu> wrote: > I would expect a client version to be communicated over libsvn_ra_svn in > a string, not a word. The original design intent was that words are > only for enumerated protocol values understood by the ra_svn code itself. > > It seems like we departed from this design with #2991 when we made a set > of ra_svn words visible to hook scripts. That seems like a mistake, > just as it would be a mistake to put C identifiers into the UI. > > Anyway, for the case at hand, I think the client version needs to be > marshalled as a string, not a word, and therefore not as a capability.
Is there real value in doing this? Wouldn't it be better to expose the client capabilities to the hook scripts? I don't see how you're going to avoid the user agent nonsense as long as you expose the client names and version numbers. If you take the TSVN example and image that another client decided to implement the client side hooks, then both TSVN and that hypothetical client could report a capability that specified that it supported client side hooks. With the added benefit that if the server side hook script was written for TSVN it would automatically start working for a new client, making using this feature far less burdensome. Exposing capabilities are far less likely to be abused to side step server hooks since changing the capabilities will change the behavior of the server, generally breaking the client (with the notable exception of the above TSVN client side hook example). Making a client misreport a client name and version number that is only provided to server hooks provides great incentive to modify these values. If there are behaviors of clients in the wild that hook authors want to filter on that aren't capabilities then that may override this. It seems to me that only exposing capabilities would be a far more elegant solution.
