Daniel Shahaf wrote:
> Markus Schaber wrote:
>> There are two other cases we should define a rule for:
>>
>> 1) Clients like SharpSVN or TortoiseSVN, or distribution builds, when they
>> include their own patches, or backported patches which were not officially part
>> of that release. [...]
>>
>> 2) Clients based on alternative implementations like SvnKit (is there any
>> other?).
>
> Solve both by adding a "capability" for the short client name?
>
> client-version=1.7.3 client-client=tortoisesvn
> client-version=1.7.3 client-client=svnkit
For years, as I understand, people have been using the "user-agent" string that's transmitted over HTTP
connections to identify the client when they want this sort of ability
to reject certain client versions. I assume the main problem with the
"user-agent" string is it's not available on the server in a consistent
way for all RA protocols. It would be better if it were available in a
consistent way, and an obvious way is making it available to a hook
script, as C-Mike's proposal says.
However,
the exact format of the user-agent string has been left to the
discretion of client authors. Examples from a web search:
SVN/1.0.0 neon/0.24.4
SVN/1.0.1 (dev build) neon/0.24.4
SVN/1.6.5 (r38866)/TortoiseSVN-1.6.5.16974
SVN/1.7.0-dev neon/0.29.6
SVN/1.7.2 neon/0.29.6
SVN/1.7.2/TortoiseSVN-1.7.3.22386 neon/0.29.6
SVN/1.7.2 SVNKit/1.7.0-alpha2 (http://svnkit.com/) t20120112_2133
SVN/1.8.0-dev serf/2.0.0
So can we take a clue from those examples and define something perhaps a little more formally structured but still with enough flexibility for clients to specify their own version string as well as the version of SVN libraries that they're actually or nominally based on?
- Julian
Received on 2012-02-24 10:57:54 CET