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
