Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: domain of ben@reser.org designates
 192.242.17.19 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <502E977C.80901@mit.edu>
References: <502CFF69.3050006@collab.net>
	<502E6DE7.6090905@collab.net>
	<20120817162403.GD634@ted.stsp.name>
	<20120817164149.GA28870@tarsus.local2>
	<502E86DF.4090102@collab.net>
	<502E8866.1020104@wandisco.com>
	<502E8EEE.70009@collab.net>
	<502E977C.80901@mit.edu>
Date: Fri, 17 Aug 2012 18:23:00 -0700
Message-ID: 
 <CADkdwvRzkVR52idMTFp8TAOfpTLv4NGn5fPeFMmta7eYkQaxVA@mail.gmail.com>
Subject: Re: [Issue 4124] New - Give servers sufficient means to disallow
 commits from clients based on version numbers
From: Ben Reser <ben@reser.org>
To: Subversion Development <dev@subversion.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Aug 17, 2012 at 12:11 PM, Greg Hudson <ghudson@mit.edu> wrote:
> I would expect a client version to be communicated over libsvn_ra_svn in
> a string, not a word.  The original design intent was that words are
> only for enumerated protocol values understood by the ra_svn code itself.
>
> It seems like we departed from this design with #2991 when we made a set
> of ra_svn words visible to hook scripts.  That seems like a mistake,
> just as it would be a mistake to put C identifiers into the UI.
>
> Anyway, for the case at hand, I think the client version needs to be
> marshalled as a string, not a word, and therefore not as a capability.

Is there real value in doing this?  Wouldn't it be better to expose
the client capabilities to the hook scripts?

I don't see how you're going to avoid the user agent nonsense as long
as you expose the client names and version numbers.

If you take the TSVN example and image that another client decided to
implement the client side hooks, then both TSVN and that hypothetical
client could report a capability that specified that it supported
client side hooks.  With the added benefit that if the server side
hook script was written for TSVN it would automatically start working
for a new client, making using this feature far less burdensome.

Exposing capabilities are far less likely to be abused to side step
server hooks since changing the capabilities will change the behavior
of the server, generally breaking the client (with the notable
exception of the above TSVN client side hook example).  Making a
client misreport a client name and version number that is only
provided to server hooks provides great incentive to modify these
values.

If there are behaviors of clients in the wild that hook authors want
to filter on that aren't capabilities then that may override this. It
seems to me that only exposing capabilities would be a far more
elegant solution.