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

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

From: Branko Čibej <brane_at_wandisco.com>
Date: Fri, 17 Aug 2012 21:05:48 +0200

On 17.08.2012 20:35, C. Michael Pilato wrote:
> On 08/17/2012 02:07 PM, Branko Čibej wrote:
>> On 17.08.2012 20:01, C. Michael Pilato wrote:
>>> On 08/17/2012 12:43 PM, Daniel Shahaf wrote:
>>>> 5. Require the version string and client name to match
>>>> /^[A-Za-z0-9-]+$/, and embed them directly as part of a capability
>>>> name (so: capabilities might be named client-version-tsvn-1dot7dot0)
>>> I'll give the honor of treating this suggestion as a serious one. And then
>>> the dishonor of a hearty -1. :-)
>> Why? It's essentially the same as 4., just with a different and
>> higher-level marshalling.
> Because it is higher-level marshaling. The ideal scenario keeps our
> restrictions and conversion costs as close to the layers that actually
> require them as possible. That said, I agree that in terms of the
> big-picture problem/solution set of this feature, #5 and #4 are roughly
> equivalent. I just deem #5 to be more work and less flexible than #4 for
> the creators/consumers of this information.
> I'm sitting at this spot right now: Unless we want hooks parsing literal
> capability strings such as "client-version-tsvn-1dot7dot0", we have to
> change the server. And if we have to change the server *at all* to make
> this all work, then we should simultaneously change the protocol so as not
> to require some still-obscure marshaling mechanism.

Noted. Of course this won't actually make the parsing significantly
easier for script authors, it'll just appear that way at first glance. :)

BTW, in connection with this, I've been wondering which version of what
is actually relevant here. The version of libsvn_client? The version of
the command-line tool? How does this relate to TSVN and/or SharpSVN
and/or SvnKit?

The easy answer is to let the script authors worry about that, but
without at least some kind of guideline, that's a good way of
reproducing the user-agent madness. For example, it would very probably
make sense for TortoiseSVN to report the version of the Subversion
libraries it's built with, but I'm not at all clear how to sanely
formulate such a rule.

-- Brane

Certified & Supported Apache Subversion Downloads:
Received on 2012-08-17 21:06:26 CEST

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