[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Branch 1.5.x: mod_dav_svn restricts third-party Subversion clients too much.

From: Stefan Küng <tortoisesvn_at_gmail.com>
Date: Fri, 14 Mar 2008 21:42:39 +0100

Karl Fogel wrote:
> Stefan Küng <tortoisesvn_at_gmail.com> writes:
>> Subversion 1.5 allows clients to modify the user-agent string so it
>> can include the actual client used.
>>
>> Check the 'client_name' member of svn_client_ctx_t in the file
>> http://svn.collab.net/repos/svn/branches/1.5.x/subversion/include/svn_client.h
>>
>> I think SVNKit should do it the same way as Subversion 1.5.
>
> Stefan,
>
> His concern is the reverse: our *server* is checking for a particular
> user agent string prefix, and the question is what should SVNKit
> transmit in order to cause the right recognition by mod_dav_svn.

I remember we had this discussion when I first suggested the custom user
agent string. I had to change my patch to make sure that it had 'SVN/'
first and *then* the custom part.

As far as I understand, SVNKit just wants to use a custom string so it's
recognized as a different client. The indication of capabilities is done
  in the first part and (correct me if I'm wrong) has nothing to do with
the client library but only with the numbers after the 'SVN/'.

I doubt that mod_dav_svn would interpret the numbers/capabilities
differently if 'SVNKit/' instead of 'SVN/' was the first part of the string.

So, SVNKit could use the same first part of the user-agent string as the
svn library, and then add the custom part at the end, as svn 1.5 does.

Or am I completely off the road here? (wouldn't be the first time :)

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.net

Received on 2008-03-14 21:43:03 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.