RE: Problem with adding files in SVN 1.8.0+. Is it in the tracker already?
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:b...@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.janiko...@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
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? Kind regards Jan -- From: Bert Huijben [mailto:b...@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: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
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 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:b...@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.janiko...@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
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.janiko...@alstom.commailto:jan.janiko...@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.
