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