On Wed, Feb 22, 2012 at 11:13 AM, <cmpil...@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@subversion > Reported by|cmpilato > > > > > > > ------- Additional comments from cmpil...@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
