Re: Problem with adding files in SVN 1.8.0+. Is it in the tracker already?

[Thorsten Schöning]

Guten Tag Geoff Field,
am Mittwoch, 25. September 2013 um 02:25 schrieben Sie:

> Hi Bert,[...]

Please don't rely on everyone is seeing HTML mails by default, I don't
and your answer is almost useless as plain text.

http://www.netmeister.org/news/learn2quote.html

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning   E-Mail:thorsten.schoen...@am-soft.de
AM-SoFT IT-Systeme  http://www.AM-SoFT.de/

Telefon...05151-  9468- 55
Fax...05151-  9468- 88
Mobil..0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow

RE: Problem with adding files in SVN 1.8.0+. Is it in the tracker already?

[Geoff Field]

Good evening Thorsten,

> Guten Tag Geoff Field,
> am Mittwoch, 25. September 2013 um 02:25 schrieben Sie:
> 
> > Hi Bert,[...]
> 
> Please don't rely on everyone is seeing HTML mails by 
> default,

My apologies.  My only excuse (apart from laziness) is that the post to which I 
replied was in HTML.

> I don't and your answer is almost useless as plain text.

And I thought *I* was a throwback ;-)

> http://www.netmeister.org/news/learn2quote.html

There's a difference between "being taught" and "learning".  The latter relies 
on actually *remembering* what a teacher has tried to hammer through one's 
skull.

For those who do not or will not run an email client with HTML capabilities 
turned on, here is the post in plain text format:

From: Bert Huijben [mailto:b...@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?

> 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 posted the 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 it in nearly every case.  There were rare occasions when the add/commit 
would just work, but in the majority of cases it would fail.  


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. 

Re: Problem with adding files in SVN 1.8.0+. Is it in the tracker already?

[Thorsten Schöning]

Guten Tag Geoff Field,
am Mittwoch, 25. September 2013 um 09:38 schrieben Sie:

> And I thought *I* was a throwback ;-)

I can see HTML, that's not the problem, it's just not the default for
the folder were this mail is presented and I think usable plain text
ist still good practice on mailing lists.

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning   E-Mail:thorsten.schoen...@am-soft.de
AM-SoFT IT-Systeme  http://www.AM-SoFT.de/

Telefon...05151-  9468- 55
Fax...05151-  9468- 88
Mobil..0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow

encoding issue with ruby binding

[Stephane D'Alu]

Version:
Subversion: 1.8.3
Ruby: 2.0.0.195

Error message:
/usr/local/lib/ruby/site_ruby/2.0/svn/info.rb:236:in `===': invalid byte
sequence in US-ASCII (ArgumentError)

It occurs in the "parse_diff_unified" methods when trying to mach lines
of "entry.body"


How to repeat:
Having an UTF-8 encoded character in a committed file


-- 
Stephane D'Alu -- Ingenieur Recherche
Laboratoire CITI / INSA-Lyon
Tel: +33 47243 6483

RE: Problem with adding files in SVN 1.8.0+. Is it in the tracker already?

[Bert Huijben]

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_fi...@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:b...@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.janiko...@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 com

Re: svn: warning: W120171: Error running context: An error occurred during SSL communication

[Lieven Govaerts]

Hi,

On Tue, Sep 24, 2013 at 4:33 PM, Niemann, Hartmut
 wrote:
> Hello!
>
>
>
> What is going wrong if I get
>
> svn: warning: W120171: Error running context: An error
> occurred during SSL communication
>
> five out of six times I try to update a repository or to do some other
> subversion command?
>

the error code comes from the serf library, more specifically this is
error SERF_ERROR_SSL_COMM_FAILED.
It indicates that the OpenSSL library reported an error during ssl/tls
communication. It should be unrelated to certificate validation as
that's another error code.

>
> (This is Tortoise SVN/64
>
> TortoiseSVN 1.8.2, Build 24708 - 64 Bit , 2013/08/27 19:20:39
>
> Subversion 1.8.3, -release
>
> apr 1.4.8
> apr-util 1.5.2
> serf 1.3.1
> OpenSSL 1.0.1e 11 Feb 2013
> zlib 1.2.8
>
>
>
> and it’s command line tool
>
>
> svn, version 1.8.3 (r1516576)
>
>compiled Aug 27 2013, 22:13:03 on x86-microsoft-windows [...]
>
> * ra_serf : Module for accessing a repository via WebDAV protocol using
> serf.
>
>   - using serf 1.3.1
>   - handles 'http' scheme
>   - handles 'https' scheme
> on Windows 7)
>
>
>
> The problems started yesterday (tsvn 1.8.1, about 3 out of 4 tries failed),
> today nothing works.
>

Was something in the server configuration related to ssl/tls modified?
Or, do you use a proxy server that was changed recently?

> I upgraded to 1.8.3, tried both the gui and the command line version.
>
> Where do I have to look for the cause of this failure?
>

First of all check the apache access and error logs, if the server
raised an ssl alert it should be in the logs.
Second, run wireshark.
  If you're using a proxy, check that the ssl tunnel setup was done
correctly. Also check that the proxy is not configured to close the
connection after the first request (Connection:Close header on the
response to the CONNECT request).
  Check if there are ssl alerts, check if it's the client or the
server that closed the connection, check if session initialisation was
successful.
Third, get yourself a build of serf with logging activated (#define
SSL_VERBOSE 1), send the logs to the list or to me privately, should
give us a lot of info to analyse what's wrong.

Lieven

>
> Mit freundlichen Grüßen
> Dr. Hartmut Niemann
>
> Siemens AG
> Infrastructure & Cities Sector
> Rail Systems Division
> Locomotives and Components
> IC RL LOC EN LE 8
> Werner-von-Siemens-Str. 67
> 91052 Erlangen, Deutschland
> Tel: +49 9131 7-34264
> Fax: +49 9131 7-26254
> mailto:hartmut.niem...@siemens.com
>
> Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Gerhard Cromme;
> Vorstand: Joe Kaeser, Vorsitzender; Roland Busch, Brigitte Ederer, Klaus
> Helmrich, Barbara Kux, Hermann Requardt, Siegfried Russwurm, Peter Y.
> Solmssen, Michael Süß; Sitz der Gesellschaft: Berlin und München,
> Deutschland; Registergericht: Berlin Charlottenburg, HRB 12300, München, HRB
> 6684; WEEE-Reg.-Nr. DE 23691322

second commit is failing if space is in file name or file path

[Kesavan Sengodan]

Hi

We are using Subversion (SVN 1.6.12-r955802) for our repo. This subversion and 
the modules (dav_svn_module & authz_svn_module) provided by it, are working 
fine with previous Apache version 2.2.24.

Since the Apache version 2.2.24 has some security issues (multi-site secutity 
issue), we have moved to Apache version 2.2.25. But this updated version has 
the second commit issue. Issue details are given below.

"The issue with Apache 2.2.25 is when you have 'space' in folder name / file 
name. The first commit of these files / folders (with space in the name) is 
successful. We are facing issue only when subsequent commit is happening. We 
are using Tortoise SVN as client"

We are almost blocked to use the subversion now.

Kindly provide us some workaround and hotfix for this issue.

Regards
Kesavan Sengodan

Re: second commit is failing if space is in file name or file path

[Ivan Zhakov]

On 25 September 2013 18:50, Kesavan Sengodan
 wrote:
> Hi
>
> We are using Subversion (SVN 1.6.12-r955802) for our repo. This subversion
> and the modules (dav_svn_module & authz_svn_module) provided by it, are
> working fine with previous Apache version 2.2.24.
>
It's known problem in Apache HTTP Server 2.2.25:
https://issues.apache.org/bugzilla/show_bug.cgi?id=55397

The only known solution is to revert these buggy changes in Apache HTTP Server:
http://svn.haxx.se/dev/archive-2013-08/0479.shtml

-- 
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com

RE: Problem with adding files in SVN 1.8.0+. Is it in the tracker already?

[Bert Huijben]

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:b...@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_fi...@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:b...@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.janiko...@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 t

Commit ignoring whitespace changes

[Zé]

Does subversion provide a way to commit all changes except those that 
affect only whitespaces?


Thanks,
Zé

Re: Commit ignoring whitespace changes

[Ryan Schmidt]

On Sep 25, 2013, at 16:19, Zé  wrote:

> Does subversion provide a way to commit all changes except those that affect 
> only whitespaces?

Nothing built in for that, no.

I recommend whitespace changes be a separate commit from functional changes. 
But it's up to the developers to do that. The tool doesn't do it for you.

RE: Problem with adding files in SVN 1.8.0+. Is it in the tracker already?

[Geoff Field]

Hi Bert,

From: Bert Huijben [mailto:b...@qqmail.nl] 
Sent: Wednesday, 25 September 2013 21:04 PM
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.

As much as Outlook (and I know you're using Outlook because the headers of your 
message include "X-Mailer: Microsoft Outlook 15.0") is a sub-optimal tool for 
traditional groups, it's not that hard to change the "Format" selection from 
"HTML" to "Plain Text".

The real problem/pain is that you then have to reformat the message to make 
sense in plain-text format.  I haven't done much to this message and it's a bit 
of a mess.

>   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've given as much detail as I can in the various emails, but I think Philip 
has had problems getting the exact version loaded.

>   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.

Yes, that seems to be happening a lot.  Even now after updating versions I'm 
getting a lot of 401s in the log.

>   What authentication configuration does your apache use?

We're using an authz file.  Specifically, we have:

Options Indexes FollowSymLinks

DAV svn
SVNListParentPath On
SVNParentPath L:/Subversion/Repositories
SSLRequireSSL

# Keep these in sync with location /websvn below
AuthType SSPI
#   AuthType None
AuthName "Subversion repositories"
SSPIAuth On
SSPIAuthoritative On
SSPIDomain AAPL
SSPIOfferBasic On
Require valid-user

AuthzSVNAccessFile L:/Subversion/conf/svnaccessfile.conf


And yes, I've just double-checked that the /websvn location is identical.

 
>   NTLM/Digest/Basic, with what backend.

Our LoadModules for auth connections include the following lines (omitting the 
commented-out ones):

LoadModule auth_basic_module modules/mod_auth_basic.so
LoadModule sspi_auth_module modules/mod_auth_sspi.so
LoadModule authn_default_module modules/mod_authn_default.so
LoadModule authn_file_module modules/mod_authn_file.so
LoadModule authz_default_module modules/mod_authz_default.so
LoadModule authz_groupfile_module modules/mod_authz_groupfile.so
LoadModule authz_host_module modules/mod_authz_host.so
LoadModule authz_user_module modules/mod_authz_user.so
LoadModule authz_svn_module modules/mod_authz_svn.so

On the server, the Services applet gives the following Description information 
for Apache 2 (which is no longer active because it's where we get the problems):

Apache/2.0.54 (win32) DAV/2
mod_ssl/2.0.55
OpenSSL/0.9.8 SVN/1.2.3
mod_python/3.1.3
Python/2.3.5 PHP/5.0.4
mod_auth_sspi/1.0.3

If I've missed anything important, please feel free to give me more detailed 
information on what you need.

>   What is the maximum number of requests per connection?

I'm not entirely sure.  From the Apache2 httpd.conf, I see:


ThreadsPerChild 250
MaxRequestsPerChild  0


I'm not entirely sure if the mpm_winnt module is enabled.


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

I'll reply off-list with the full httpd.conf for Apache2.  There is nothing in 
there that I consider secret.  The authz file is another story, of course, but 
I'll send a copy of that with just the Playground repo information.

>   Thanks,
>
>   Bert

And thanks for your attention and patience, too.

Regards,

Geoff
 

 

 

From: Geoff Field [mailto:geoff_fi...@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:b...@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 k

RE: Problem with adding files in SVN 1.8.0+. Is it in the tracker already?

[Geoff Field]

Thanks Bert,

I appreciate the effort.

(Top-posting, but at least it's in plain-text format...)

Geoff
 

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


 




From: Bert Huijben [mailto:b...@qqmail.nl] 
Sent: Thursday, 26 September 2013 2:13 AM
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 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:b...@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_fi...@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:b...@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