From users-return-19736-apmail-subversion-users-archive=subversion.apache.org@subversion.apache.org Wed Sep 25 16:13:56 2013 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 9CBA010B10 for ; Wed, 25 Sep 2013 16:13:56 +0000 (UTC) Received: (qmail 10239 invoked by uid 500); 25 Sep 2013 16:13:47 -0000 Delivered-To: apmail-subversion-users-archive@subversion.apache.org Received: (qmail 9572 invoked by uid 500); 25 Sep 2013 16:13:40 -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 9559 invoked by uid 99); 25 Sep 2013 16:13:39 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 25 Sep 2013 16:13:39 +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 (nike.apache.org: local policy includes SPF record at spf.trusted-forwarder.org) Received: from [209.85.212.176] (HELO mail-wi0-f176.google.com) (209.85.212.176) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 25 Sep 2013 16:13:32 +0000 Received: by mail-wi0-f176.google.com with SMTP id cb5so5703246wib.3 for ; Wed, 25 Sep 2013 09:13:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-type:thread-index:content-language; bh=xy91pXlL0YRLXjSpccGHQijPAqnbi4zLYR/c7vTXrmQ=; b=NYMZ2r0s67kv8iM8ZeOoIh+BehdOPbu2BmU8uSia5y5tmwAJn5xmZs3RkhHo5TLJRW dlqkpW/UYL32kxj5NvdaLJut7gJTd5EWgIkT9CeAz2DBV4RxjBHQ/uBd92ALVGTafl+p UGsMMLA+ck78fQ5+lkmqnnXwtD76N3+lPMZWjYj3aztDRpW9+GjOTkLU+BuS5gfmfjDm DJzzwvEIQX7A5gzTJp4+G9FtvszNG0Q9DOsPYJnJhSxhGwA7MzWsDuEYL6N7PJMOITW7 a9vDKe7H65RNDMbyfvls0D2CApPMuz1KdEt4jQOuPeYJF7y+y17hsX3/iKpOmbkkPmL4 Rg8g== X-Gm-Message-State: ALoCoQmBoXD1YMAL2ClIMZBGd7RJy3LiA/b5vfgfRpRtsfnefAyvuwW7a3UZBCni/jG15N85g6oc X-Received: by 10.180.187.236 with SMTP id fv12mr15110454wic.20.1380125592099; Wed, 25 Sep 2013 09:13:12 -0700 (PDT) Received: from i72600 ([2001:610:66e:0:59f6:6194:a164:dbd7]) by mx.google.com with ESMTPSA id i8sm19365537wiy.6.1969.12.31.16.00.00 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 25 Sep 2013 09:13:11 -0700 (PDT) From: "Bert Huijben" To: "'Geoff Field'" , "'JANIKOVIC Jan'" , References: <00E5011532EFBB4FAAB1279AD4C3FBCB1883F855@041-DB3MPN2-142.041d.mgd.msft.net> <000a01ceb966$a6608830$f3219890$@qqmail.nl> <4A2A8BDDBE6EFE4199FB22121DB971B102625B1C@AAPLExchange.aapl.com.au> <006201ceb9df$0002c470$00084d50$@qqmail.nl> In-Reply-To: <006201ceb9df$0002c470$00084d50$@qqmail.nl> Subject: RE: Problem with adding files in SVN 1.8.0+. Is it in the tracker already? Date: Wed, 25 Sep 2013 18:12:55 +0200 Message-ID: <00b501ceba0a$19e15480$4da3fd80$@qqmail.nl> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B6_01CEBA1A.DD6BD230" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIEVZHNBcPIn1BFlHajIb2qRldevwHXE1nWAZuUuDABv4qwS5lByyXA Content-Language: nl X-Virus-Checked: Checked by ClamAV on apache.org This is a multipart message in MIME format. ------=_NextPart_000_00B6_01CEBA1A.DD6BD230 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I think I found a bug causing your specific problems in 'serf', Subversions new default http library. The problem doesn't appear to affect Subversion users unless the server closes connections aggressively. 'HEAD' requests (as requests without a body) don't trigger the authentication subsystem. The 401 from the HEAD request as shown in your log file is assumed to be a 'file exists' status. A patch is available on the serf development list. I assume it (or a similar patch) will be included in the next serf version. Bert From: Bert Huijben [mailto:bert@qqmail.nl] Sent: woensdag 25 september 2013 13:04 To: 'Geoff Field'; 'JANIKOVIC Jan'; users@subversion.apache.org Subject: RE: Problem with adding files in SVN 1.8.0+. Is it in the tracker already? I'll just reply in the html form as it will be very hard to convert this thread to plain ascii and I have better things to do than spending half an hour on that. The information in your e-mail says that you can reproduce it on your working copy; and then Philip Martin says he can't reproduce it. I looked through your apache log (attached in yet another followup) and noticed that about every request first fails with a 401 error and then later succeeds. What authentication configuration does your apache use? NTLM/Digest/Basic, with what backend. What is the maximum number of requests per connection? Can you send us your apache config (with sensitive information replaced by dummy information of course) Thanks, Bert From: Geoff Field [mailto:Geoff_Field@aapl.com.au] Sent: woensdag 25 september 2013 02:25 To: Bert Huijben; 'JANIKOVIC Jan'; users@subversion.apache.org Subject: RE: Problem with adding files in SVN 1.8.0+. Is it in the tracker already? Hi Bert, _____ From: Bert Huijben [ mailto:bert@qqmail.nl] Sent: Wednesday, 25 September 2013 6:43 AM To: 'JANIKOVIC Jan'; users@subversion.apache.org Subject: RE: Problem with adding files in SVN 1.8.0+. Is it in the tracker already? No, There is no issue for this specific part of those threads created as nobody was able to produce a reproduction recipe for this problem to the developers yet. Surely it would be useful to add the issue report anyway, even if there is no easy way to reproduce it. After all, it is a known issue now. We can then work on the reproduction recipe. All the threads you quoted end with this request. So unless you add a way to reproduce the problem (perhaps with the help of the earlier reporters) to the discussion there is not much we can do for you at this time/ I'm sure I postedthe method for me to reproduce it. We were running a 1.2.3 server served by Apache 2.0.54 on Windows Server 2003 SP2. I was then using a 1.8.1 client on Windows 7 Pro 32-bit. I thought I'd posted my recipe here: http://svn.haxx.se/users/archive-2013-08/0035.shtml However, this is NOT the full recipe. Instead, look at this post: http://svn.haxx.se/users/archive-2013-08/0140.shtml That contains the steps I took to reliably produce errors with the server/client setup we had. Unlike most of our repositories, the Playground repo has always been FSFS. The problem happened with our BDB repos as well. The problem doesn't reproduce with the currently supported versions, nor with the older versions we tried to setup specifically to trigger the problem quoted here. But it's easily reproduced here, and obviously is at other sites too. Do you see the problem in all working copies, or just in certain scenarios? (E.g. multiple levels of added directories? Mixed revision copies? Etc. etc.) I saw itin nearly every case. There were rare occasions when the add/commit would just work, but in the majority of cases it would fail. Bert From: JANIKOVIC Jan [mailto:jan.janikovic@power.alstom.com] Sent: dinsdag 24 september 2013 12:51 To: users@subversion.apache.org Subject: Problem with adding files in SVN 1.8.0+. Is it in the tracker already? Hello, There seems to be a problem with the TortoiseSVN1.8.0+, which returns a server conflict when a new file is attempted to be added. We observed the problem only when adding files to the server running SVN1.5.5. No problems were observed when adding files to our second server, running SVN 1.7.x. There are further posts about this issue on the Internet, such as https://groups.google.com/d/topic/tortoisesvn/cGoClRBMCPc/discussion or https://groups.google.com/d/msg/tortoisesvn/NggY3JzVJIY/gdEklFV2vLgJ Is this issue already in the Subversion tracker ( http://subversion.apache.org/reporting-issues.html)? If yes, could you please tell me the issue number Kind regards Jan Jan Janikovic ALPRO Implementation Specialist Regards, Geoff -- Apologies for the auto-generated legal boilerplate added by our IT department: - The contents of this email, and any attachments, are strictly private and confidential. - It may contain legally privileged or sensitive information and is intended solely for the individual or entity to which it is addressed. - Only the intended recipient may review, reproduce, retransmit, disclose, disseminate or otherwise use or take action in reliance upon the information contained in this email and any attachments, with the permission of Australian Arrow Pty. Ltd. - If you have received this communication in error, please reply to the sender immediately and promptly delete the email and attachments, together with any copies, from all computers. - It is your responsibility to scan this communication and any attached files for computer viruses and other defects and we recommend that it be subjected to your virus checking procedures prior to use. - Australian Arrow Pty. Ltd. does not accept liability for any loss or damage of any nature, howsoever caused, which may result directly or indirectly from this communication or any attached files. ------=_NextPart_000_00B6_01CEBA1A.DD6BD230 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

I think I found a bug causing your specific = problems in ‘serf’, Subversions new default http = library.

 

The problem = doesn’t appear to affect Subversion users unless the server closes = connections aggressively. ‘HEAD’ requests (as requests = without a body) don’t trigger the authentication subsystem. The = 401 from the HEAD request as shown in your log file is assumed to be a = ‘file exists’ status.

 

A patch is available on = the serf development list. I assume it (or a similar patch) will be = included in the next serf version.

 

        &= nbsp;       Bert

 

From: Bert = Huijben [mailto:bert@qqmail.nl]
Sent: woensdag 25 september = 2013 13:04
To: 'Geoff Field'; 'JANIKOVIC Jan'; = users@subversion.apache.org
Subject: RE: Problem with adding = files in SVN 1.8.0+. Is it in the tracker = already?

 

I’ll just reply in the html form as it = will be very hard to convert this thread to plain ascii and I have = better things to do than spending half an hour on = that.

 

The information in your = e-mail says that you can reproduce it on your working copy; and then = Philip Martin says he can’t reproduce it.

 

I looked through your = apache log (attached in yet another followup) and noticed that about = every request first fails with a 401 error and then later = succeeds.

 

What authentication = configuration does your apache use?

 

NTLM/Digest/Basic, with = what backend.

What is the maximum number of requests per = connection?

 

Can you send us your = apache config (with sensitive information replaced by dummy information = of course)

 

Thanks,

        &= nbsp;       Bert

 

 

 

 

Hi= Bert,

 

From:= = Bert Huijben [mailto:bert@= qqmail.nl] =
Sent: Wednesday, 25 September 2013 6:43 AM
To: = 'JANIKOVIC Jan'; users@subver= sion.apache.org
Subje= ct: RE: Problem with adding files in SVN 1.8.0+. Is it in the = tracker already?

        &= nbsp;       No,

 

There is no issue for = this specific part of those threads created as nobody was able to = produce a reproduction recipe for this problem to the developers = yet.&n= bsp;

Surely it would be useful to add the issue report = anyway, even if there is no easy way to reproduce it.  After all, = it is a known issue now.  We can then work on the reproduction = recipe.

 

All the threads you = quoted end with this request… So unless you add a way to reproduce = the problem (perhaps with the help of the earlier reporters) to the = discussion there is not much we can do for you at this = time/

I'= m sure I postedthe method for me to reproduce = it.   &n= bsp;We were running a 1.2.3 server served by Apache 2.0.54 on Windows = Server 2003 SP2.  I was then using a 1.8.1 client on = Windows 7 Pro 32-bit.  I thought I'd posted my recipe = here:

 

http://svn.haxx.se/users/archive-2013-08/0035.= shtml

Ho= wever, this is NOT the full recipe. In= stead, look at this post:

http://svn.ha= xx.se/users/archive-2013-08/0140.shtml

Th= at contains the steps I took to reliably = produce errors with the server/client setup we had.  Unlike most of = our repositories, the Playground repo has always been FSFS.  = The problem happened with our BDB repos as well.

The problem = doesn’t reproduce with the currently supported versions, nor with = the older versions we tried to setup specifically to trigger the problem = quoted here.

Bu= t it's easily reproduced here, and obviously is at other sites = too.

 

Do you see the problem in all working copies, or = just in certain scenarios? (E.g. multiple levels of added directories? = Mixed revision copies? Etc. etc.)

I = saw itin nearly every = case.  There were rare occasions when the add/commit would just = work, but in the majority of cases it would = fail.  

 

        &= nbsp;       Bert

 

Hello,

 

There seems to be a problem = with the TortoiseSVN1.8.0+, which returns a server conflict when a new = file is attempted to be added. We observed the problem only when adding = files to the server running SVN1.5.5. No problems were observed when = adding files to our second server, running SVN 1.7.x. There are further = posts about this issue on the Internet, such as https://groups.google.com/d/to= pic/tortoisesvn/cGoClRBMCPc/discussion

or =

https://groups.google.com/d/ms= g/tortoisesvn/NggY3JzVJIY/gdEklFV2vLgJ

 

Is = this issue already in the Subversion tracker (http://subversion.apache.org/r= eporting-issues.html)? If yes, could you please = tell me the issue number

 

Kind = regards

Jan

 

= Jan Janikovic

= ALPRO Implementation Specialist&n= bsp;

Re= gards,

 

Ge= off=  

 

--
Apologies for the auto-generated legal boilerplate added by our = IT department:= 

- The contents of this email, and any =
attachments, are strictly private
and =
confidential.
- It may contain legally privileged =
or sensitive information and is intended
solely for =
the individual or entity to which it is =
addressed.
- Only the intended recipient may =
review, reproduce, retransmit, =
disclose,
disseminate or otherwise use or take =
action in reliance upon the information
contained =
in this email and any attachments, with the permission =
of
Australian Arrow Pty. =
Ltd.
- If you have received this communication in =
error, please reply to the sender
immediately and =
promptly delete the email and attachments, together =
with
any copies, from all =
computers.
- It is your responsibility to scan this =
communication and any attached files
for computer =
viruses and other defects and we recommend that it =
be
subjected to your virus checking procedures =
prior to use.
- Australian Arrow Pty. Ltd. does not =
accept liability for any loss or damage
of any =
nature, howsoever caused, which may result
directly =
or indirectly from this communication or any attached files. =

 
------=_NextPart_000_00B6_01CEBA1A.DD6BD230--