subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From JANIKOVIC Jan <jan.janiko...@power.alstom.com>
Subject RE: Problem with adding files in SVN 1.8.0+. Is it in the tracker already?
Date Mon, 23 Dec 2013 11:58:10 GMT
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.

Mime
View raw message