subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Shahaf <...@daniel.shahaf.name>
Subject Re: SVN Server Configuration To Restrict SVN Client Version
Date Mon, 19 Nov 2012 03:35:49 GMT
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).
> ************************************************************************************
> 
> 

Mime
View raw message