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:bert_at_qqmail.nl]
Sent: Montag, 23. Dezember 2013 15:07
To: JANIKOVIC Jan; 'Geoff Field'; users_at_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_at_power.alstom.com]
> Sent: maandag 23 december 2013 12:58
> To: Bert Huijben; 'Geoff Field'; users_at_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_at_qqmail.nl]
> Sent: Montag, 23. Dezember 2013 12:10
> To: JANIKOVIC Jan; 'Geoff Field'; users_at_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_at_power.alstom.com]
> > Sent: maandag 23 december 2013 11:52
> > To: Bert Huijben; 'Geoff Field'; users_at_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.