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