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