Uploaded image for project: 'Subversion'
  1. Subversion
  2. SVN-4124

Give servers sufficient means to disallow commits from clients based on version numbers



    • Improvement
    • Status: Closed
    • Major
    • Resolution: Fixed
    • 1.7.x
    • 1.8.0
    • libsvn_ra
    • None


      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
      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




            cmpilato C. Michael Pilato
            cmpilato C. Michael Pilato
            0 Vote for this issue
            2 Start watching this issue