[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: Paul Burba <ptburba_at_gmail.com>
Date: Thu, 23 Feb 2012 10:32:35 -0500

On Wed, Feb 22, 2012 at 11:13 AM, <cmpilato_at_tigris.org> wrote:
> http://subversion.tigris.org/issues/show_bug.cgi?id=4124
>                 Issue #|4124
>                 Summary|Give servers sufficient means to disallow commits from
>                        | clients based on version numbers
>               Component|subversion
>                 Version|1.7.x
>                Platform|All
>                     URL|
>              OS/Version|All
>                  Status|NEW
>       Status whiteboard|
>                Keywords|
>              Resolution|
>              Issue type|ENHANCEMENT
>                Priority|P3
>            Subcomponent|libsvn_ra
>             Assigned to|issues_at_subversion
>             Reported by|cmpilato
>
>
>
>
>
>
> ------- Additional comments from cmpilato_at_tigris.org Wed Feb 22 08:13:31 -0800 2012 -------
> I'm seeing more and more requests from admins (in public and private channels)
> seeking ways to ensure that the users of their repositories are committing with
> a particular pedigree of client, namely one that meets some version number
> threshold.
>
> In the past, we frowned on the idea of such version-number-centric mechanisms
> for allowing/denying commit access, citing the ease with which the value can be
> spoofed and opting instead to push for capabilities strings that carried more
> specific information ("supports merge tracking", or "supports atomic revision
> property changes", etc.).  The problem we are seeing now is two-fold:
>
> 1.  As a community, we the developers aren't particularly good at identifying
> which changes that we make to the client codebase are of the sort that justify a
> new capability string.  So, we've been extremely conservative about adding them,
> even though practically each new merge-tracking related bugfix is likely a
> reason to wish clients weren't using un-fixed clients.
>
> 2.  As implied above, there are in reality many more such interesting changes
> than we wish to individually track.  I mean, do we *really* want to see the
> likes of "merginfo, atomic-revprops, fix-for-issue-5911,
> fix-for-the-commit-part-of-issue-5621, subtree-mergeinfo-minimized,
> subtree-mergeinfo-minimized-round-2, ..."?
>
> Why not just give users what they want?  A capability string (or comparable
> mechanism) that carries the client's version number, for use with start-commit
> hooks in allowing/denying clients which don't meet the administrator's quality
> requirements?

Mike,

+1 to this enhancement. One question though, are you envisioning a
new "capability" for each minor release or for each patch release? I
assume the latter, but that's not entirely clear from the issue
writeup.

Paul
Received on 2012-02-23 16:33:09 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.