You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by JANIKOVIC Jan <ja...@power.alstom.com> on 2013/09/24 12:50:40 UTC
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
--------------------------------------------------------------
ALSTOM (Switzerland) Ltd
TEC-TE, Konnex 3L2
Brown Boveri Strasse 7
5401 Baden
Switzerland
Tel: +41 (0) 58 505 48 26
Fax: +41 (0) 58 505 64 09
jan.janikovic@alstom.com<ma...@alstom.com>
http://www.alstom.com/power/
________________________________
CONFIDENTIALITY : This e-mail and any attachments are confidential and may be privileged. If you are not a named recipient, please notify the sender immediately and do not disclose the contents to another person, use it for any purpose or store or copy the information in any medium.
RE: Outlook macro for proper quoting (was RE: Problem with adding
files in SVN 1.8.0+. Is it in the tracker already?)
Posted by Geoff Field <Ge...@aapl.com.au>.
> From: Andrew Reedick
> > From: Geoff Field
> > Sent: Wednesday, September 25, 2013 7:27 PM
> > Hi Bert,
> >
> > From: Bert Huijben
> > Sent: Wednesday, 25 September 2013 21:04 PM
> >
> >> 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.
>
> For those suffering from the embarrassment of posting with
> Outlook clients: "QuoteFix Macro" at
> http://sourceforge.net/apps/mediawiki/macros4outlook/index.php?title=QuoteFix_Macro#Configuration
Thanks Andrew,
I've found that with a very small effort and a little manual
configuration, I can produce a reasonably formatted post without
upsetting the modern conventions used by most of the others
within our business.
Having said that, I've applied QuoteFix on my Outlook Express at
home (some time in the past). I'm reluctant to apply it on my
work computers, though - if our firewall even allows downloads
from SourceForge (it's a bit fussy in some very odd ways).
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.
Outlook macro for proper quoting (was RE: Problem with adding files
in SVN 1.8.0+. Is it in the tracker already?)
Posted by Andrew Reedick <An...@cbeyond.net>.
> -----Original Message-----
> From: Geoff Field [mailto:Geoff_Field@aapl.com.au]
> Sent: Wednesday, September 25, 2013 7:27 PM
> 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 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.
For those suffering from the embarrassment of posting with Outlook clients: "QuoteFix Macro" at http://sourceforge.net/apps/mediawiki/macros4outlook/index.php?title=QuoteFix_Macro#Configuration
RE: Problem with adding files in SVN 1.8.0+. Is it in the tracker
already?
Posted by Geoff Field <Ge...@aapl.com.au>.
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:bert@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: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 <ma...@qqmail.nl> ]
Sent: Wednesday, 25 September 2013 6:43 AM
To: 'JANIKOVIC Jan'; users@subversion.apache.org <ma...@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 <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 <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 <https://groups.google.com/d/topic/tortoisesvn/cGoClRBMCPc/discussion>
or
https://groups.google.com/d/msg/tortoisesvn/NggY3JzVJIY/gdEklFV2vLgJ <https://groups.google.com/d/msg/tortoisesvn/NggY3JzVJIY/gdEklFV2vLgJ>
Is this issue already in the Subversion tracker (http://subversion.apache.org/reporting-issues.html <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
- 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?
Posted by JANIKOVIC Jan <ja...@power.alstom.com>.
Hello Bert,
First of all, happy New Year. I hope you had a nice time over the holidays.
Our Subversion 1.5.5 is integrated with TeamForge 5.2. TeamForge is responsible for all configuration.
As we have a support contract with CollabNet, the developer of TeamForge, I have already raised the issue because of the logs you asked for (I was not sure if they contain sensitive information) and send them the copy of the session and the respective logs.
I was able to reproduce the issue by SlikSVN 1.8.5, as well by CollabNet subversion 1.8.5.1 client. I am not sure if you use the same libraries as CollabNet (or even work with them) but I think so. If this is true and considering that they already are after the issue I propose to wait for their feedback - or eventually for their fix, which may influence SlikSVN and TortoiseSVN.
I will keep you posted.
Kind regards
Jan
-----Original Message-----
From: Bert Huijben [mailto:bert@qqmail.nl]
Sent: Montag, 23. Dezember 2013 15:07
To: JANIKOVIC Jan; 'Geoff Field'; users@subversion.apache.org
Subject: RE: Problem with adding files in SVN 1.8.0+. Is it in the tracker already?
> -----Original Message-----
> From: JANIKOVIC Jan [mailto:jan.janikovic@power.alstom.com]
> Sent: maandag 23 december 2013 12:58
> To: Bert Huijben; 'Geoff Field'; users@subversion.apache.org
> Subject: RE: Problem with adding files in SVN 1.8.0+. Is it in the
> tracker already?
>
> Hello Bert,
>
> Would these reproduction steps help? If there is a way how to get a
> log
file,
> or any other way to help fixing this issue, please let me know:
>
> Server installation: RHEL 4, Subversion svn, version 1.5.5 Computer
> installation: TortoiseSVN 1.8.4, serf 1.3.2, computer restarted
after
> installation
I'm developing on Windows, so this makes it very hard to replicate this problem for me...
Eventually your old report made it possible to replicate the HEAD problem for me on Windows, which made me debug serf and Subversion.
And even then I would setup my repository using a pretty standard configuration using a normal password backend; the default number of requests, etc. etc. Your older reports noted that you didn't use a plain text password backend, etc.
That is 100% essential information to get things reproduced for anybody.
Requiring a specific pretty old, platform to reproduce anything is making it less likely that anybody can reproduce it.
Did you try your setup (=config files) on a setup that is actively supported by any of the commercial vendors?
If you can that would really help.
> 1. Repository updated
How do you update a repository?
Let's assume
$ svnadmin create REPOSITORY
And hooking that to a url http://my-server/svn/repos
$ svn import greekfiles http://my-server/svn/repos/ -m ""
<answer username password, store in cache>
Adding greekfiles\A
Adding greekfiles\A\B
Adding greekfiles\A\B\E
Adding greekfiles\A\B\E\alpha
Adding greekfiles\A\B\E\beta
Adding greekfiles\A\B\F
Adding greekfiles\A\B\lambda
Adding greekfiles\A\C
Adding greekfiles\A\D
Adding greekfiles\A\D\G
Adding greekfiles\A\D\G\pi
Adding greekfiles\A\D\G\rho
Adding greekfiles\A\D\G\tau
Adding greekfiles\A\D\H
Adding greekfiles\A\D\H\chi
Adding greekfiles\A\D\H\omega
Adding greekfiles\A\D\H\psi
Adding greekfiles\A\D\gamma
Adding greekfiles\A\mu
Adding greekfiles\iota
Committed revision 1.
So now we have a repository...
(See our FAQ and 'HACKING' for some tricks to setup test environments)
> 2. File "new.txt" with arbitrary content copied to the repository
> folder
on the
> computer
Copying files to a repository directory is never recommended. Let's assume you are talking about a working copy
$ svn co http://my-server/svn/repos wc
$ touch wc/new.txt
$ svn add wc/new.txt
> 3. Right-mouse click on the new file: TortoiseSVN->Add 4. Right-mouse
> click on the new file: SVN Commit 5. Press OK on the Commit dialog
> that appears
On this list we +- assume that you use 'svn', so let's assume that you did $ svn commit -m "Message" wc Adding wc\new.txt Committed revision 2.
> 6. Form "Authentication" appears with following text:
> <server name> Authorization Realm
>
> Request username and password
> Username: [textbox]
> Password: [textbox]
> [checkbox] Save Authentication
This eventually documents that you did setup authentication on your repository. We should add that information to step 1.
>
> 7. After third attempt to enter the login commit fails with following
message:
>
>
----------------------------------------------------------------------------
----
> Error: Commit failed (details follow):
> Error: No more credentials or we tried too many times.
> Error: Authentication failed
> Error: Additional errors:
> Error: Error running context: The requested authentication type(s) are
> not supported
>
----------------------------------------------------------------------------
----
In your original report you didn't get authentication prompts here, so something changed.
It would be very useful to add the updated server error logs here too. The thing we try to solve is why these request fails and we now just know that the authentication failed.
I don't know the exact details, but I remember something about Kerberos. Are you used to seeing password prompts? (If you are using Kerberos/ntlm you usually only see prompts when there is a problem connecting using the default method) Did you really type the right username and password (casing, prefix/vs no prefix). Did some ticket expire?
The server log would be very informative here. (Like we explained in the original report) as it usually has more details than what you do want to send to your users.
The exact error message you note here is raised in our http layer after the server reported the credentials as invalid 4 times. (The first might be an attempt without a password; not sure). The original problem was that we didn't authenticate a HEAD request at all. It would be good to know if this works correctly now and if it is still the same request that fails.
> As for the tracker, adding the issue to it would help testers to see
> in
which
> version of serf, or svn client the bug was fixed and then I, or other
interested
> parties, could test the fix when it will be added to TortoiseSVN. We
> could benefit also from the history in one location. Furthermore at
> the
beginning I
> spent some time to find the related discussion about this bug I
> believe
that
> other passive users of Tortoise SVN would find it easier to see that
> something is being done with this issue and that there is no
> workaround present yet apart from downgrading. That just how I see it.
As I see it adding an issue in this stage where an issue is reported by a single party, without a way to reproduce it for anybody else is just a way to postpone the problem. Maybe it is nice to see that it is still not resolved with Subversion 1.10 and 1.11, but I'm more looking forward to resolve the problem. If you just want to the state tracked for you I would recommend asking one of the commercial parties backing the Subversion development. (FYI: My work is indirectly paid from the income of that)
Other users can't really look at the existing issue as without a clear reproducible description there is no way to know that their issue is really the same issue as this one. The issue tracker is for know/identified issues that we should be able to solve given enough time/resources and for feature ideas that we may/may not implement later.
Bert
>
> Kind regards
> Jan
>
>
>
> -----Original Message-----
> From: Bert Huijben [mailto:bert@qqmail.nl]
> Sent: Montag, 23. Dezember 2013 12:10
> To: JANIKOVIC Jan; 'Geoff Field'; users@subversion.apache.org
> Cc: PETERS Michael
> Subject: RE: Problem with adding files in SVN 1.8.0+. Is it in the
> tracker already?
>
>
>
> > -----Original Message-----
> > From: JANIKOVIC Jan [mailto:jan.janikovic@power.alstom.com]
> > Sent: maandag 23 december 2013 11:52
> > To: Bert Huijben; 'Geoff Field'; users@subversion.apache.org
> > Cc: PETERS Michael
> > Subject: RE: Problem with adding files in SVN 1.8.0+. Is it in the
> > tracker already?
> >
> > Hello Bert,
> >
> > Thank you for looking into this problem and for working on it. I
> > tested
> the file
> > addition in TortoiseSVN1.8.4 using serf 1.3.2 (released on Oct. 4,
> > after
> your
> > fix). The issue still exists there, but the behaviour is different
> compared to
> > TortoiseSVN 1.8.3: When user attempts to commit an added file, he is
> > prompted for login. Even when correct login is provided, the login
> > dialog appears again two more times after which the commit fails.
> > There is still
> no
> > tracker (TortoiseSVN, Subversion.Apache or serf) where this issue
> > would be tracked. Would it be possible to add it to one of these
trackers?
>
> What would it help any of us to add it to a tracker?
>
> That doesn't magically solve this problem, does it?
>
> What we need is a good report of the problem that makes it possible to
> fix the problem. If we have that information we can fix it directly,
> or we
might
> (for different reasons) postpone fixing the problem. In that case it
> helps
to
> add it to a tracker.
>
> Just adding issues to a tracker just slows down fixing the actual problem.
> Issues require maintenance and it is not like we -as open source
> project-
pay
> somebody to do that. And issues with not enough information to fix it
> will eventually (perhaps in a few years) just be closed as something
> like 'WORKSFORME' by a developer that takes the time to look through
> the issue tracker to see if there are things he can fix.
>
>
> Personally I'm quite easy to convince to fix an issue directly when
somebody
> hands me the information to reproduce the problem they see.
>
> If the issue is really important I'm even able to drop other work at
> hand
trying
> to solve it. (Just compare the list traffic to the Subversion commits
> if
you
> need some examples :)). In this case an issue number is perhaps nice
> for
the
> changelog, but it doesn't really help either.
>
>
> The best bug reports are just a few simple steps that show how any
> developer can reproduce and debug the problem. (Well, perhaps patches
> are even better... but we can't expect the average user to debug
> through the low level network implementations)
>
>
>
> The information that the new serf changes the behavior is really
interesting,
> but then you note that 'the commit fails'. There are at least
> 1000 different reasons why a commit can fail, so that last bit really
doesn't
> help. Usually serf produces very cryptical, but for a developer very
> informative error messages and I would really recommend posting the
> errors you see here. (Or as noted a few times before: how we can see
> the errors for
> ourselves)
>
>
> Bert
>
>
> ________________________________
> CONFIDENTIALITY : This e-mail and any attachments are confidential and
> may be privileged. If you are not a named recipient, please notify the
> sender immediately and do not disclose the contents to another person,
> use it for any purpose or store or copy the information in any medium.
________________________________
CONFIDENTIALITY : This e-mail and any attachments are confidential and may be privileged. If you are not a named recipient, please notify the sender immediately and do not disclose the contents to another person, use it for any purpose or store or copy the information in any medium.
RE: Problem with adding files in SVN 1.8.0+. Is it in the tracker already?
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: JANIKOVIC Jan [mailto:jan.janikovic@power.alstom.com]
> Sent: maandag 23 december 2013 12:58
> To: Bert Huijben; 'Geoff Field'; users@subversion.apache.org
> Subject: RE: Problem with adding files in SVN 1.8.0+. Is it in the tracker
> already?
>
> Hello Bert,
>
> Would these reproduction steps help? If there is a way how to get a log
file,
> or any other way to help fixing this issue, please let me know:
>
> Server installation: RHEL 4, Subversion svn, version 1.5.5
> Computer installation: TortoiseSVN 1.8.4, serf 1.3.2, computer restarted
after
> installation
I'm developing on Windows, so this makes it very hard to replicate this
problem for me...
Eventually your old report made it possible to replicate the HEAD problem
for me on Windows, which made me debug serf and Subversion.
And even then I would setup my repository using a pretty standard
configuration using a normal password backend; the default number of
requests, etc. etc. Your older reports noted that you didn't use a plain
text password backend, etc.
That is 100% essential information to get things reproduced for anybody.
Requiring a specific pretty old, platform to reproduce anything is making it
less likely that anybody can reproduce it.
Did you try your setup (=config files) on a setup that is actively supported
by any of the commercial vendors?
If you can that would really help.
> 1. Repository updated
How do you update a repository?
Let's assume
$ svnadmin create REPOSITORY
And hooking that to a url http://my-server/svn/repos
$ svn import greekfiles http://my-server/svn/repos/ -m ""
<answer username password, store in cache>
Adding greekfiles\A
Adding greekfiles\A\B
Adding greekfiles\A\B\E
Adding greekfiles\A\B\E\alpha
Adding greekfiles\A\B\E\beta
Adding greekfiles\A\B\F
Adding greekfiles\A\B\lambda
Adding greekfiles\A\C
Adding greekfiles\A\D
Adding greekfiles\A\D\G
Adding greekfiles\A\D\G\pi
Adding greekfiles\A\D\G\rho
Adding greekfiles\A\D\G\tau
Adding greekfiles\A\D\H
Adding greekfiles\A\D\H\chi
Adding greekfiles\A\D\H\omega
Adding greekfiles\A\D\H\psi
Adding greekfiles\A\D\gamma
Adding greekfiles\A\mu
Adding greekfiles\iota
Committed revision 1.
So now we have a repository...
(See our FAQ and 'HACKING' for some tricks to setup test environments)
> 2. File "new.txt" with arbitrary content copied to the repository folder
on the
> computer
Copying files to a repository directory is never recommended. Let's assume
you are talking about a working copy
$ svn co http://my-server/svn/repos wc
$ touch wc/new.txt
$ svn add wc/new.txt
> 3. Right-mouse click on the new file: TortoiseSVN->Add
> 4. Right-mouse click on the new file: SVN Commit
> 5. Press OK on the Commit dialog that appears
On this list we +- assume that you use 'svn', so let's assume that you did
$ svn commit -m "Message" wc
Adding wc\new.txt
Committed revision 2.
> 6. Form "Authentication" appears with following text:
> <server name> Authorization Realm
>
> Request username and password
> Username: [textbox]
> Password: [textbox]
> [checkbox] Save Authentication
This eventually documents that you did setup authentication on your
repository. We should add that information to step 1.
>
> 7. After third attempt to enter the login commit fails with following
message:
>
>
----------------------------------------------------------------------------
----
> Error: Commit failed (details follow):
> Error: No more credentials or we tried too many times.
> Error: Authentication failed
> Error: Additional errors:
> Error: Error running context: The requested authentication type(s) are not
> supported
>
----------------------------------------------------------------------------
----
In your original report you didn't get authentication prompts here, so
something changed.
It would be very useful to add the updated server error logs here too. The
thing we try to solve is why these request fails and we now just know that
the authentication failed.
I don't know the exact details, but I remember something about Kerberos. Are
you used to seeing password prompts? (If you are using Kerberos/ntlm you
usually only see prompts when there is a problem connecting using the
default method)
Did you really type the right username and password (casing, prefix/vs no
prefix). Did some ticket expire?
The server log would be very informative here. (Like we explained in the
original report) as it usually has more details than what you do want to
send to your users.
The exact error message you note here is raised in our http layer after the
server reported the credentials as invalid 4 times. (The first might be an
attempt without a password; not sure). The original problem was that we
didn't authenticate a HEAD request at all. It would be good to know if this
works correctly now and if it is still the same request that fails.
> As for the tracker, adding the issue to it would help testers to see in
which
> version of serf, or svn client the bug was fixed and then I, or other
interested
> parties, could test the fix when it will be added to TortoiseSVN. We could
> benefit also from the history in one location. Furthermore at the
beginning I
> spent some time to find the related discussion about this bug I believe
that
> other passive users of Tortoise SVN would find it easier to see that
> something is being done with this issue and that there is no workaround
> present yet apart from downgrading. That just how I see it.
As I see it adding an issue in this stage where an issue is reported by a
single party, without a way to reproduce it for anybody else is just a way
to postpone the problem. Maybe it is nice to see that it is still not
resolved with Subversion 1.10 and 1.11, but I'm more looking forward to
resolve the problem. If you just want to the state tracked for you I would
recommend asking one of the commercial parties backing the Subversion
development. (FYI: My work is indirectly paid from the income of that)
Other users can't really look at the existing issue as without a clear
reproducible description there is no way to know that their issue is really
the same issue as this one. The issue tracker is for know/identified issues
that we should be able to solve given enough time/resources and for feature
ideas that we may/may not implement later.
Bert
>
> Kind regards
> Jan
>
>
>
> -----Original Message-----
> From: Bert Huijben [mailto:bert@qqmail.nl]
> Sent: Montag, 23. Dezember 2013 12:10
> To: JANIKOVIC Jan; 'Geoff Field'; users@subversion.apache.org
> Cc: PETERS Michael
> Subject: RE: Problem with adding files in SVN 1.8.0+. Is it in the tracker
> already?
>
>
>
> > -----Original Message-----
> > From: JANIKOVIC Jan [mailto:jan.janikovic@power.alstom.com]
> > Sent: maandag 23 december 2013 11:52
> > To: Bert Huijben; 'Geoff Field'; users@subversion.apache.org
> > Cc: PETERS Michael
> > Subject: RE: Problem with adding files in SVN 1.8.0+. Is it in the
> > tracker already?
> >
> > Hello Bert,
> >
> > Thank you for looking into this problem and for working on it. I
> > tested
> the file
> > addition in TortoiseSVN1.8.4 using serf 1.3.2 (released on Oct. 4,
> > after
> your
> > fix). The issue still exists there, but the behaviour is different
> compared to
> > TortoiseSVN 1.8.3: When user attempts to commit an added file, he is
> > prompted for login. Even when correct login is provided, the login
> > dialog appears again two more times after which the commit fails.
> > There is still
> no
> > tracker (TortoiseSVN, Subversion.Apache or serf) where this issue
> > would be tracked. Would it be possible to add it to one of these
trackers?
>
> What would it help any of us to add it to a tracker?
>
> That doesn't magically solve this problem, does it?
>
> What we need is a good report of the problem that makes it possible to fix
> the problem. If we have that information we can fix it directly, or we
might
> (for different reasons) postpone fixing the problem. In that case it helps
to
> add it to a tracker.
>
> Just adding issues to a tracker just slows down fixing the actual problem.
> Issues require maintenance and it is not like we -as open source project-
pay
> somebody to do that. And issues with not enough information to fix it will
> eventually (perhaps in a few years) just be closed as something like
> 'WORKSFORME' by a developer that takes the time to look through the issue
> tracker to see if there are things he can fix.
>
>
> Personally I'm quite easy to convince to fix an issue directly when
somebody
> hands me the information to reproduce the problem they see.
>
> If the issue is really important I'm even able to drop other work at hand
trying
> to solve it. (Just compare the list traffic to the Subversion commits if
you
> need some examples :)). In this case an issue number is perhaps nice for
the
> changelog, but it doesn't really help either.
>
>
> The best bug reports are just a few simple steps that show how any
> developer can reproduce and debug the problem. (Well, perhaps patches
> are even better... but we can't expect the average user to debug through
> the low level network implementations)
>
>
>
> The information that the new serf changes the behavior is really
interesting,
> but then you note that 'the commit fails'. There are at least
> 1000 different reasons why a commit can fail, so that last bit really
doesn't
> help. Usually serf produces very cryptical, but for a developer very
> informative error messages and I would really recommend posting the errors
> you see here. (Or as noted a few times before: how we can see the errors
> for
> ourselves)
>
>
> Bert
>
>
> ________________________________
> CONFIDENTIALITY : This e-mail and any attachments are confidential and may
> be privileged. If you are not a named recipient, please notify the sender
> immediately and do not disclose the contents to another person, use it for
> any purpose or store or copy the information in any medium.
RE: Problem with adding files in SVN 1.8.0+. Is it in the tracker
already?
Posted by JANIKOVIC Jan <ja...@power.alstom.com>.
Hello Bert,
Would these reproduction steps help? If there is a way how to get a log file, or any other way to help fixing this issue, please let me know:
Server installation: RHEL 4, Subversion svn, version 1.5.5
Computer installation: TortoiseSVN 1.8.4, serf 1.3.2, computer restarted after installation
1. Repository updated
2. File "new.txt" with arbitrary content copied to the repository folder on the computer
3. Right-mouse click on the new file: TortoiseSVN->Add
4. Right-mouse click on the new file: SVN Commit
5. Press OK on the Commit dialog that appears
6. Form "Authentication" appears with following text:
<server name> Authorization Realm
Request username and password
Username: [textbox]
Password: [textbox]
[checkbox] Save Authentication
7. After third attempt to enter the login commit fails with following message:
--------------------------------------------------------------------------------
Error: Commit failed (details follow):
Error: No more credentials or we tried too many times.
Error: Authentication failed
Error: Additional errors:
Error: Error running context: The requested authentication type(s) are not supported
--------------------------------------------------------------------------------
As for the tracker, adding the issue to it would help testers to see in which version of serf, or svn client the bug was fixed and then I, or other interested parties, could test the fix when it will be added to TortoiseSVN. We could benefit also from the history in one location. Furthermore at the beginning I spent some time to find the related discussion about this bug I believe that other passive users of Tortoise SVN would find it easier to see that something is being done with this issue and that there is no workaround present yet apart from downgrading. That just how I see it.
Kind regards
Jan
-----Original Message-----
From: Bert Huijben [mailto:bert@qqmail.nl]
Sent: Montag, 23. Dezember 2013 12:10
To: JANIKOVIC Jan; 'Geoff Field'; users@subversion.apache.org
Cc: PETERS Michael
Subject: RE: Problem with adding files in SVN 1.8.0+. Is it in the tracker already?
> -----Original Message-----
> From: JANIKOVIC Jan [mailto:jan.janikovic@power.alstom.com]
> Sent: maandag 23 december 2013 11:52
> To: Bert Huijben; 'Geoff Field'; users@subversion.apache.org
> Cc: PETERS Michael
> Subject: RE: Problem with adding files in SVN 1.8.0+. Is it in the
> tracker already?
>
> Hello Bert,
>
> Thank you for looking into this problem and for working on it. I
> tested
the file
> addition in TortoiseSVN1.8.4 using serf 1.3.2 (released on Oct. 4,
> after
your
> fix). The issue still exists there, but the behaviour is different
compared to
> TortoiseSVN 1.8.3: When user attempts to commit an added file, he is
> prompted for login. Even when correct login is provided, the login
> dialog appears again two more times after which the commit fails.
> There is still
no
> tracker (TortoiseSVN, Subversion.Apache or serf) where this issue
> would be tracked. Would it be possible to add it to one of these trackers?
What would it help any of us to add it to a tracker?
That doesn't magically solve this problem, does it?
What we need is a good report of the problem that makes it possible to fix the problem. If we have that information we can fix it directly, or we might (for different reasons) postpone fixing the problem. In that case it helps to add it to a tracker.
Just adding issues to a tracker just slows down fixing the actual problem.
Issues require maintenance and it is not like we -as open source project- pay somebody to do that. And issues with not enough information to fix it will eventually (perhaps in a few years) just be closed as something like 'WORKSFORME' by a developer that takes the time to look through the issue tracker to see if there are things he can fix.
Personally I'm quite easy to convince to fix an issue directly when somebody hands me the information to reproduce the problem they see.
If the issue is really important I'm even able to drop other work at hand trying to solve it. (Just compare the list traffic to the Subversion commits if you need some examples :)). In this case an issue number is perhaps nice for the changelog, but it doesn't really help either.
The best bug reports are just a few simple steps that show how any developer can reproduce and debug the problem. (Well, perhaps patches are even better... but we can't expect the average user to debug through the low level network implementations)
The information that the new serf changes the behavior is really interesting, but then you note that 'the commit fails'. There are at least
1000 different reasons why a commit can fail, so that last bit really doesn't help. Usually serf produces very cryptical, but for a developer very informative error messages and I would really recommend posting the errors you see here. (Or as noted a few times before: how we can see the errors for
ourselves)
Bert
________________________________
CONFIDENTIALITY : This e-mail and any attachments are confidential and may be privileged. If you are not a named recipient, please notify the sender immediately and do not disclose the contents to another person, use it for any purpose or store or copy the information in any medium.
RE: Problem with adding files in SVN 1.8.0+. Is it in the tracker already?
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: JANIKOVIC Jan [mailto:jan.janikovic@power.alstom.com]
> Sent: maandag 23 december 2013 11:52
> To: Bert Huijben; 'Geoff Field'; users@subversion.apache.org
> Cc: PETERS Michael
> Subject: RE: Problem with adding files in SVN 1.8.0+. Is it in the tracker
> already?
>
> Hello Bert,
>
> Thank you for looking into this problem and for working on it. I tested
the file
> addition in TortoiseSVN1.8.4 using serf 1.3.2 (released on Oct. 4, after
your
> fix). The issue still exists there, but the behaviour is different
compared to
> TortoiseSVN 1.8.3: When user attempts to commit an added file, he is
> prompted for login. Even when correct login is provided, the login dialog
> appears again two more times after which the commit fails. There is still
no
> tracker (TortoiseSVN, Subversion.Apache or serf) where this issue would be
> tracked. Would it be possible to add it to one of these trackers?
What would it help any of us to add it to a tracker?
That doesn't magically solve this problem, does it?
What we need is a good report of the problem that makes it possible to fix
the problem. If we have that information we can fix it directly, or we might
(for different reasons) postpone fixing the problem. In that case it helps
to add it to a tracker.
Just adding issues to a tracker just slows down fixing the actual problem.
Issues require maintenance and it is not like we -as open source project-
pay somebody to do that. And issues with not enough information to fix it
will eventually (perhaps in a few years) just be closed as something like
'WORKSFORME' by a developer that takes the time to look through the issue
tracker to see if there are things he can fix.
Personally I'm quite easy to convince to fix an issue directly when somebody
hands me the information to reproduce the problem they see.
If the issue is really important I'm even able to drop other work at hand
trying to solve it. (Just compare the list traffic to the Subversion commits
if you need some examples :)). In this case an issue number is perhaps nice
for the changelog, but it doesn't really help either.
The best bug reports are just a few simple steps that show how any developer
can reproduce and debug the problem. (Well, perhaps patches are even
better... but we can't expect the average user to debug through the low
level network implementations)
The information that the new serf changes the behavior is really
interesting, but then you note that 'the commit fails'. There are at least
1000 different reasons why a commit can fail, so that last bit really
doesn't help. Usually serf produces very cryptical, but for a developer very
informative error messages and I would really recommend posting the errors
you see here. (Or as noted a few times before: how we can see the errors for
ourselves)
Bert
RE: Problem with adding files in SVN 1.8.0+. Is it in the tracker
already?
Posted by JANIKOVIC Jan <ja...@power.alstom.com>.
Hello Bert,
Thank you for looking into this problem and for working on it. I tested the file addition in TortoiseSVN1.8.4 using serf 1.3.2 (released on Oct. 4, after your fix). The issue still exists there, but the behaviour is different compared to TortoiseSVN 1.8.3: When user attempts to commit an added file, he is prompted for login. Even when correct login is provided, the login dialog appears again two more times after which the commit fails. There is still no tracker (TortoiseSVN, Subversion.Apache or serf) where this issue would be tracked. Would it be possible to add it to one of these trackers?
Kind regards
Jan
----------------------------------------------------------------------------------------------------------------------------------
From: Bert Huijben [mailto:bert@qqmail.nl]
Sent: Mittwoch, 25. September 2013 18:13
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: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.
________________________________
CONFIDENTIALITY : This e-mail and any attachments are confidential and may be privileged. If you are not a named recipient, please notify the sender immediately and do not disclose the contents to another person, use it for any purpose or store or copy the information in any medium.
RE: Problem with adding files in SVN 1.8.0+. Is it in the tracker already?
Posted by Bert Huijben <be...@qqmail.nl>.
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
<ma...@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 [ <ma...@qqmail.nl> mailto:bert@qqmail.nl]
Sent: Wednesday, 25 September 2013 6:43 AM
To: 'JANIKOVIC Jan'; <ma...@subversion.apache.org>
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>
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>
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 <ma...@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>
https://groups.google.com/d/topic/tortoisesvn/cGoClRBMCPc/discussion
or
<https://groups.google.com/d/msg/tortoisesvn/NggY3JzVJIY/gdEklFV2vLgJ>
https://groups.google.com/d/msg/tortoisesvn/NggY3JzVJIY/gdEklFV2vLgJ
Is this issue already in the Subversion tracker (
<http://subversion.apache.org/reporting-issues.html>
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.
RE: Problem with adding files in SVN 1.8.0+. Is it in the tracker
already?
Posted by Geoff Field <Ge...@aapl.com.au>.
Hi Bert,
From: Bert Huijben [mailto:bert@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:
<Location /Subversion/>
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
</Location>
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:
<IfModule mpm_winnt.c>
ThreadsPerChild 250
MaxRequestsPerChild 0
</IfModule>
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_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 <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.
RE: Problem with adding files in SVN 1.8.0+. Is it in the tracker already?
Posted by Bert Huijben <be...@qqmail.nl>.
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
<ma...@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>
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 <ma...@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.
Re: Problem with adding files in SVN 1.8.0+. Is it in the tracker already?
Posted by Thorsten Schöning <ts...@am-soft.de>.
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.Schoening@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?
Posted by Geoff Field <Ge...@aapl.com.au>.
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: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?
> 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?
Posted by Thorsten Schöning <ts...@am-soft.de>.
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.Schoening@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?
Posted by Geoff Field <Ge...@aapl.com.au>.
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 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.
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.
RE: Problem with adding files in SVN 1.8.0+. Is it in the tracker already?
Posted by Bert Huijben <be...@qqmail.nl>.
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.
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/
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.
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.)
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
--------------------------------------------------------------
ALSTOM (Switzerland) Ltd
TEC-TE, Konnex 3L2
Brown Boveri Strasse 7
5401 Baden
Switzerland
Tel: +41 (0) 58 505 48 26
Fax: +41 (0) 58 505 64 09
<ma...@alstom.com> jan.janikovic@alstom.com
<http://www.alstom.com/power/> http://www.alstom.com/power/
_____
CONFIDENTIALITY : This e-mail and any attachments are confidential and may
be privileged. If you are not a named recipient, please notify the sender
immediately and do not disclose the contents to another person, use it for
any purpose or store or copy the information in any medium.