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).
************************************************************************************