Hi Daniel,
Thanks for the response. As I think you understand, enforcing restrictions on the SVN client version is not aimed at preventing intentional spoofing, but rather human error and occasionally, sloth. In both cases, a refusal from the repository to accept access is generally all that is needed to prompt the user to comply. (Forging the version is much more work than installing the proper package.)
From your response and the thread you pointed at, I understand that there is no plan to integrate this capability before the 1.8 release, so I'll probably fall back to plan B - which is to check the SVN client version as part of the project build process. Not my first choice (and has some obvious holes), but it'll have to do until then.
Thanks Again,
Nathan
-----Original Message-----
From: Daniel Shahaf [mailto:d.s_at_daniel.shahaf.name]
Sent: Mon 11/19/2012 5:35 AM
To: Nathan Frid
Cc: users_at_subversion.apache.org
Subject: Re: SVN Server Configuration To Restrict SVN Client Version
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).
> ************************************************************************************
>
>
************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses(100).
************************************************************************************
************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses(42).
************************************************************************************
************************************************************************************
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 15:40:19 CET