First of all: there is nothing you can do to prevent people from self-compiling a 1.0 client that identifies as a 1.9 client.
Now, with that out of the way: - You today can use the 'capabilities' argument to the 'start-commit' to approximate client version. - See http://subversion.tigris.org/issues/show_bug.cgi?id=4124 , to be included in 1.8.0: http://subversion.apache.org/docs/release-notes/1.8#ephemeral-txnprops Nathan Frid wrote on Sun, Nov 18, 2012 at 13:56:06 +0200: > Hi All, > > > > Having upgraded and deployed SVN 1.7 some time ago for > the repositories I manage, I am still encountering users who have not > upgraded from 1.6, despite repeated requests. Worse yet, the Linux > distribution we use doesn't package SVN 1.7 out-of-the-box, so sometimes > simple human error results in use of an old client. I would like to > configure the SVN server to reject access (or at least write access) > from pre-1.7 clients. > > > > I found nothing helpful in the SVN book and searching through the > mailing-list archives, I found only an old thread from 2009 which did > not provide a solution. The responses were more along the lines of > "what for?". But I have found pressing needs to enforce > standardization: > > > > 1) From an administrative/support perspective, it is MUCH easier to > support the same, or a minimum, version across all users in the > organization than deal with the variations in versions, especially > regarding bugs long since resolved. > > 2) SVN 1.6 handles merge tracking for sub-tree merges differently > than SVN 1.7 regarding what the 1.7 release notes call "reduced subtree > mergeinfo recording". This was one of the important (for us, at least) > improvements in SVN 1.7, as it makes the change logs much easier to > read, but according to the release notes, "Best results will be achieved > for new branches created and maintained exclusively with 1.7 clients". > So to fully realize the benefit, I have to restrict the client version. > Worse yet, I recently encountered a tree conflict due to 1.6's handling > of subtree mergeinfo. Say we have a branch A. A user with a 1.6 client > further branches "A", and through merge operations, manages to cause SVN > to track mergeinfo for a single file, "file.txt". Following > reintegration, a new branch "B" is created. After "B" was created, > "file.txt" is deleted from "A". On "B" development continues, including > branching and merging, but no content changes are made to "file.txt". > Upon reintegration of "B" to "A", a spurious tree conflict is detected > because the mergeinfo of "file.txt" on "B" was modified (for no good > reason), while that same file was deleted on "A". > > > > Does anyone have a solution or could point me in the right direction? > > > > Thanks, > > Nathan > > > > > > > ************************************************************************************ > This footnote confirms that this email message has been scanned by > PineApp Mail-SeCure for the presence of malicious code, vandals & computer > viruses(187). > ************************************************************************************ > >
