Return-Path: X-Original-To: apmail-subversion-users-archive@minotaur.apache.org Delivered-To: apmail-subversion-users-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 5750AD3CD for ; Sun, 18 Nov 2012 16:00:54 +0000 (UTC) Received: (qmail 12665 invoked by uid 500); 18 Nov 2012 16:00:53 -0000 Delivered-To: apmail-subversion-users-archive@subversion.apache.org Received: (qmail 12205 invoked by uid 500); 18 Nov 2012 16:00:47 -0000 Mailing-List: contact users-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@subversion.apache.org Delivered-To: moderator for users@subversion.apache.org Received: (qmail 71854 invoked by uid 99); 18 Nov 2012 11:54:39 -0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,MIME_QP_LONG_LINE,SPF_HELO_PASS,SPF_PASS,UNPARSEABLE_RELAY X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of Nathan.Frid@alvarion.com designates 95.35.11.187 as permitted sender) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CDC583.63856419" Subject: SVN Server Configuration To Restrict SVN Client Version Date: Sun, 18 Nov 2012 13:56:06 +0200 Message-ID: <56439212F1FB0D45B3354883689F42455D1FFD@yoqex01.alvarion.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SVN Server Configuration To Restrict SVN Client Version Thread-Index: Ac3Fg7EQlOx1U+Y6TZusx+ISBwaogQ== From: "Nathan Frid" To: X-Virus-Checked: Checked by ClamAV on apache.org This is a multi-part message in MIME format. ------_=_NextPart_001_01CDC583.63856419 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 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. =20 =20 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: =20 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". =20 Does anyone have a solution or could point me in the right direction? =20 Thanks, Nathan =20 =20 ************************************************************************************ This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses(187). ************************************************************************************ ------_=_NextPart_001_01CDC583.63856419 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

         &= nbsp;      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?

 

       &n= bsp;           &nb= sp;           &nbs= p;        Thanks,

       &n= bsp;           &nb= sp;           &nbs= p;        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).
************************************************************************************
------_=_NextPart_001_01CDC583.63856419--