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