Re: [Issue 4124] New - Give servers sufficient means to disallow commits from clients based on version numbers

Trying to revive an old thread...

Daniel Shahaf wrote:
> Markus Schaber wrote on Fri, Feb 24, 2012 at 08:09:30 +0000:
>> 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. Especially Debian tends to prefer
>> backporting of fixes over updating to new releases.
>>
>> 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

The point of this feature is to give server admins (or more specifically,
repository hook authors) the ability to make decisions about
allowing/disallowing interaction with particular clients. But, like Julian,
I want to avoid having this explode into something as adhoc as a User-Agent
string. Is it realistic to think that a server admin is going to make an
"interaction is allowed" decision based on whether the client is a specific
version of a Debian build with particular bugfix patches applied? That
seems like overkill to me. Further, every expansion of the valid
capability-string space we make is an additional burden to hook authors.

So, incorporating some of the great suggestions on this thread so far, but
adding some of my own, I'd like to reset this design discussion with the
following proposal:

   # Reports the general name of the client.
   #
   # Examples: "svn", "tortoisesvn", "svnkit"
   #
   # Default value: "svn".
   #
   client-name=[-_a-zA-Z0-9]+

   # Reports the specific version of the client.
   #
   # Examples: "1.6.0a2", "1.5.4dfsg1-1ubuntu2.1"
   #
   # Default value: ${SVN_VER_NUMBER}
   #
   client-version=[-_a-zA-Z0-9\.\+]+

   # Reports the version of the Apache Subversion libraries with which
   # this client is most compatible.
   #
   # Examples: "1.6.0", "1.8.0-dev", "1.7.0-alpha1"
   #
   # Default value: ${SVN_VER_NUMBER}
   #
   client-compat-version=[0-9]+\.[0-9]+\.[0-9]+(-[a-z0-9]+)?

Here are some examples:

   client-name=svn
   client=version=1.8.0-dev
   client-compat-version=1.8.0-dev

   client-name=svnkit
   client-version=1.7.5-v1
   client-compat-version=1.7.5

   client-name=tortoisesvn
   client-version=1.7.8
   client-compat-version=1.7.6

   client-name=svn
   client=version=1.5.4dfsg1-1ubuntu2.1
   client-compat-version=1.5.4

I think this will allow the best of both worlds for hook authors: the
deeper insight needed to rule in/rule out specific clients and client
versions, plus a way to make more general rulings based on the set of
features expected to be present in a given Apache Subversion release.

Thoughts?

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development