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).
> ************************************************************************************
>
>
Received on 2012-11-19 04:36:37 CET