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