subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bert Huijben" <b...@qqmail.nl>
Subject RE: Problem with adding files in SVN 1.8.0+. Is it in the tracker already?
Date Mon, 23 Dec 2013 11:10:28 GMT


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


Mime
View raw message