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 3478D10799 for ; Wed, 14 Aug 2013 10:06:30 +0000 (UTC) Received: (qmail 7052 invoked by uid 500); 14 Aug 2013 10:06:29 -0000 Delivered-To: apmail-subversion-users-archive@subversion.apache.org Received: (qmail 7024 invoked by uid 500); 14 Aug 2013 10:06:29 -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 Received: (qmail 7005 invoked by uid 99); 14 Aug 2013 10:06:29 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 14 Aug 2013 10:06:29 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of felipe.alvarez@gmail.com designates 209.85.217.172 as permitted sender) Received: from [209.85.217.172] (HELO mail-lb0-f172.google.com) (209.85.217.172) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 14 Aug 2013 10:06:23 +0000 Received: by mail-lb0-f172.google.com with SMTP id o7so6739385lbv.17 for ; Wed, 14 Aug 2013 03:06:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=LfVTKX2VwhiXUp/NRK7BYMcNctY13NFV65y85v/Hdr4=; b=R0V2kH4It6MVR6mMDEOqsbslpklbyvHE4BLLLWVw4aGjNAObLA//O8c7Gpwl4ThxvR L93X7UPCXhZOkNxNaJlNerhQs5dZe5LaSDLUDKvAc0+DfMHDkeNqz1PjD5uqkP0RKz3Y en+sQNBCdGjzoPn0+ERoKAC6ufY8/6Aio11+ngD4taJvX9fi3pmZBAhy9+cLEiKSYpJj q2xiK840ltIlGRW3Rnk66dsMmxI51ted7kvuphMGzwbW0c8XPIddxsE89X4JHM9IlO2s ucVIU8ks569tFN7Q9dGinvUY502osYiAT+6qdGK58o1Vz4GSKp2Q2BynYeqh1Ln4Ekta zDUw== X-Received: by 10.152.8.115 with SMTP id q19mr7770182laa.16.1376474762372; Wed, 14 Aug 2013 03:06:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.76.244 with HTTP; Wed, 14 Aug 2013 03:05:22 -0700 (PDT) In-Reply-To: <201308130806.r7D86eip076324@ot.x0.to> References: <1035764031.20130804165847@am-soft.de> <201308130806.r7D86eip076324@ot.x0.to> From: Felipe Alvarez Date: Wed, 14 Aug 2013 20:05:22 +1000 Message-ID: Subject: Re: svn 1.8 causing locks to be broken on update To: Hiroharu Tamaru Cc: Users Subversion Apache , Johan Corveleyn Content-Type: multipart/alternative; boundary=001a11c34f5c40ecd704e3e5813b X-Virus-Checked: Checked by ClamAV on apache.org --001a11c34f5c40ecd704e3e5813b Content-Type: text/plain; charset=UTF-8 > > > I have the same issue. > > It happens when I run 1.8.1 windows client with 1.6.9 https > repository sever. I haven't tried so many combinations ATM, > but here are some observations: > > 1.8.1 client run with 1.6.9 https:// repo server gives this issue. > 1.8.1 client run with 1.6.9 generated file:/// repositories are OK. > 1.8.1 client run with 1.7.6 generated file:/// repositories are OK. > 1.7.6 client run with 1.6.9 https:// repo server is OK. > > Whether the WC is freshly checked out by 1.8.1 client, or upgraded > from 1.7.6 checked out WC did not change the results. > > How's the case for the original poster? Do we see something > in common? > > # I'm reading this ML through the archives. > -- > Hiroharu > Hi Hiroharu You are indeed correct. We have done a very similar experiment here, too. We tried all of the above scenarios you gave. But our older client was 1.6.15, and we did not use https, we used http (apache 2.2) With the help of my colleague we have done some testing with svn 1.8.1 (windows 7 and Ubuntu) client and svn 1.6.15 (redhat 5.5) client. Using the file:/// method in all cases works fine (locks NOT broken). All other methods also work fine, including http. Of the tests we made, the one which breaks the locks is: client 1.8.1; repository made with svn 1.6.15; protocol HTTP (apache 2.2). One method that we have not yet tried is: client 1.8.1; repo with svn client 1.8.1; protocol HTTP How do I enabled debugging in .subversion/config or .subversion/servers? It used to be something like "neon-debug" but that's no longer available since 1.8.1 (or 1.8) -- felipe --001a11c34f5c40ecd704e3e5813b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I have the same issue.

It happens when I run 1.8.1 windows client with 1.6.9 https
repository sever. I haven't tried so many combinations ATM,
but here are some observations:

1.8.1 client run with 1.6.9 https:// repo server gives this issue.
1.8.1 client run with 1.6.9 generated file:/// repositories are OK.
1.8.1 client run with 1.7.6 generated file:/// repositories are OK.
1.7.6 client run with 1.6.9 https:// repo server is OK.

Whether the WC is freshly checked out by 1.8.1 client, or upgraded
from 1.7.6 checked out WC did not change the results.

How's the case for the original poster? Do we see something
in common?

# I'm reading this ML through the archives.
--
Hiroharu

Hi Hiroharu

You are indeed correct. We have done a very similar experiment here, too. W= e tried all of the above scenarios you gave. But our older client was 1.6.1= 5, and we did not use https, we used http (apache 2.2)

With the help of my colleague we have done some testing with svn 1.8.1 = (windows 7 and Ubuntu) client and svn 1.6.15 (redhat 5.5) client.

Using the file:/// method in all cases works fine (locks NOT broken). A= ll other methods also work fine, including http. Of the tests we made, the = one which breaks the locks is: client 1.8.1; repository made with svn 1.6.1= 5; protocol HTTP (apache 2.2).

On= e method that we have not yet tried is: client 1.8.1; repo with svn client = 1.8.1; protocol HTTP

Ho= w do I enabled debugging in .subversion/config or .subversion/servers? It u= sed to be something like "neon-debug" but that's no longer av= ailable since 1.8.1 (or 1.8)

--= felipe

--001a11c34f5c40ecd704e3e5813b--