On 2/13/07, John Peacock <jpeacock@rowman.com> wrote:
> This is a very different beast from http:// access, which is designed
> specifically to be handled over a public transport method, and to
> bootstrap on the existing Apache infrastructure. As much as possible,
> it would be prudent to maintain as much comparable features as possible
> between http:// and svn://, but there are limitations to the underlying
> protocols that may make some things easier and others difficult. As the
> main thread has progressed, it is even questionable whether the client
> version string is available to mod_dav_svn.
I don't understand what all the fuss is about in this thread. Both
http:// and svn:// network layers have feature negotiation abilities,
and have had them for years.
For http://, this is exactly what the OPTIONS request is for. That
method at least allows a client to query a server's abilities. Since
we want the opposite (the server to query the client's abilities), it
should be as simple as having mod_dav_svn examine the X-SVN-Options:
header attached to the client's' MERGE' request. This is the way (for
example) mod_dav_svn can tell the difference between an svn client and
a generic DAV client issuing a LOCK request. )Or -- perhaps even
simpler -- mod_dav_svn can look for the User-agent: header on the
request, which includes "SVN/version-number". Although feature
negotation via X-SVN-Options: is considered a better practice than
parsing version numbers.)
On the svnserve side, take a look at libsvn_ra_svn/protocol. In
section #2, it clearly explains how connection handshaking works.
There's a specific part where the client delineates its 'capabilities'
to the server. If svnserve doesn't see merge-tracking listed in the
client's features, it can refuse the connection.
So it's pretty easy to make svnserve and apache reject older clients.
The only real question is: what UI do we give to server
administrators to 'activate' this behavior? Could be something as
simple as new httpd.conf and svnserve.conf directives.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Feb 13 16:10:07 2007