Re: Subversion Exception!

27 views
Skip to first unread message

Julian Foad

unread,
Dec 12, 2018, 7:55:22 AM12/12/18
to d...@subversion.apache.org, Svn users, TortoiseSVN-dev
>> Subversion encountered a serious problem.
>> Please take the time to report this on the Subversion mailing list
[…]
>> https://subversion.apache.org/mailing-lists.html

>It is likely that this is a problem specific to TortoiseSVN, and not
>to core SVN. TortoiseSVN has its own mailinglists, so you should
>report your problem there:
(Cross-posting.)

It makes me sad every time I see this pattern. Software is often frustrating to use, but should at least aim to be polite to its users. Telling the user "Please do X" and then when the user does X saying "No, it's no good doing X; do Y" is not polite, and I would not expect anyone but the most calm, patient and helpful of users to gracefully comply with such a request.

I'm not meaning to criticise Johan but rather our whole system.

Can we please fix this problem. Both:
1) Tsvn please change the message.
2) We should pass on the report to the appropriate place and thank the user for having helped us. We, the svn commumity, should not ask the user to do that: it's our problem; the user is the annoyed victim.

That would make me happier.

- Julian

Stefan Kueng

unread,
Dec 12, 2018, 1:07:43 PM12/12/18
to TortoiseSVN-dev on behalf of Julian Foad, d...@subversion.apache.org, Svn users


On 12.12.2018 13:55, TortoiseSVN-dev on behalf of Julian Foad wrote:
>>> Subversion encountered a serious problem.
>>> Please take the time to report this on the Subversion mailing list
> […]
>>> https://subversion.apache.org/mailing-lists.html
>
>> It is likely that this is a problem specific to TortoiseSVN, and not
>> to core SVN. TortoiseSVN has its own mailinglists, so you should
>> report your problem there:
> (Cross-posting.)

Since this happens in the project monitor, my best guess is that the
path/url the user entered to be monitored is not correct.

>
> It makes me sad every time I see this pattern. Software is often frustrating to use, but should at least aim to be polite to its users. Telling the user "Please do X" and then when the user does X saying "No, it's no good doing X; do Y" is not polite, and I would not expect anyone but the most calm, patient and helpful of users to gracefully comply with such a request.
>
> I'm not meaning to criticise Johan but rather our whole system.
>
> Can we please fix this problem. Both:
> 1) Tsvn please change the message.

Sorry, won't do that. Because I've argued multiple times over the years
here that calling exit() or even abort() in a library is the worst idea
ever. Especially if this can happen by having the user enter a wrong
path/url.
Just one of the many discussions I had here:
https://lists.apache.org/thread.html/924d8493ad71b9c428f4d575540b8688481f2ba1e00b70d58a421303@1433953117@%3Cdev.subversion.apache.org%3E

if svn_xxx_canonicalize() don't guarantee that a path/uri is correct and
won't throw an exception (or return an error), then how can I in an UI
client guarantee that before passing the user input to the library?
Since I can't (only the svn lib and specifically the API that consumes
the path/uri can know what exactly it expects), I made the dialog that
catches the abort() calls show exactly this message.

I figured that maybe if you get bored answering all the users bug
reports you might reconsider and finally not call abort() but return an
error message indicating which path is wrong.

It's like I said before: imagine an image lib that simply calls abort()
every time it tries to load a corrupted image. Now imagine photoshop or
paint.net or ... uses that lib: user has maybe 10 images open, tries to
load another one and the lib calls abort(). Now the user lost the other
10 images as well because abort() ends the application with NO
possibility to either save changes first.

Sorry if this message seems rude - but I'm tired of arguing the same
over and over again.


Stefan

--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest interface to (Sub)version control
/_/ \_\ http://tortoisesvn.net

Branko Čibej

unread,
Dec 12, 2018, 3:12:09 PM12/12/18
to Stefan Kueng, TortoiseSVN-dev on behalf of Julian Foad, d...@subversion.apache.org
On 12.12.2018 19:07, Stefan Kueng wrote:
>
>
> On 12.12.2018 13:55, TortoiseSVN-dev on behalf of Julian Foad wrote:
>>>> Subversion encountered a serious problem.
>>>> Please take the time to report this on the Subversion mailing list
>> […]
>>>> https://subversion.apache.org/mailing-lists.html
>>
>>> It is likely that this is a problem specific to TortoiseSVN, and not
>>> to core SVN. TortoiseSVN has its own mailinglists, so you should
>>> report your problem there:
>> (Cross-posting.)
>
> Since this happens in the project monitor, my best guess is that the
> path/url the user entered to be monitored is not correct.
>
>>
>> It makes me sad every time I see this pattern. Software is often
>> frustrating to use, but should at least aim to be polite to its
>> users. Telling the user "Please do X" and then when the user does X
>> saying "No, it's no good doing X; do Y" is not polite, and I would
>> not expect anyone but the most calm, patient and helpful of users to
>> gracefully comply with such a request.
>>
>> I'm not meaning to criticise Johan but rather our whole system.
>>
>> Can we please fix this problem. Both:
>> 1) Tsvn please change the message.
>
> Sorry, won't do that. Because I've argued multiple times over the
> years here that calling exit() or even abort() in a library is the
> worst idea ever. Especially if this can happen by having the user
> enter a wrong path/url.


It's not the user entering the wrong path or URL. It's the code that
uses the Subversion libraries — in this case TSVN — not validating and
de-tainting its input. Yes, this has been going on for years due to your
obstinately refusing to conform to our API specs. In the meantime,
*your* users are left hanging.

The rules are clear and consistent: pointers may not be NULL unless
specifically allowed, paths must be absolute and canonical, URLs must be
canonical, all strings must be encoded in UTF-8. We provide a wide range
of helper functions that make it easy for API consumers to encode the
parameters.


> Sorry if this message seems rude - but I'm tired of arguing the same
> over and over again.


You don't say.


-- Brane

Stefan Kueng

unread,
Dec 12, 2018, 3:16:52 PM12/12/18
to Branko Čibej, TortoiseSVN-dev on behalf of Julian Foad, d...@subversion.apache.org
And as I repeatedly said: TSVN does validate the input as good as it
can. But if svn does neither describe the *exact* specs in the docs nor
provide any APIs that do that, then TSVN has to guess.
And no: specifying that paths/uris have to be "canonicalized" is not
enough because I do that, using the svn APIs.
So apparently that's not enough.


> obstinately refusing to conform to our API specs. In the meantime,
> *your* users are left hanging.

I do conform to the specs.

> The rules are clear and consistent: pointers may not be NULL unless
> specifically allowed, paths must be absolute and canonical, URLs must be
> canonical, all strings must be encoded in UTF-8. We provide a wide range
> of helper functions that make it easy for API consumers to encode the
> parameters.

That's what I do.

>> Sorry if this message seems rude - but I'm tired of arguing the same
>> over and over again.
>
>
> You don't say.

I'll leave your sarcasm and won't respond to this thread anymore.

Stefan

Branko Čibej

unread,
Dec 12, 2018, 3:47:24 PM12/12/18
to Stefan Kueng, TortoiseSVN-dev on behalf of Julian Foad, d...@subversion.apache.org
Get one of the dumps the crash reporter is supposed to generate, then
show us a stack trace that shows there's a bug in the Subversion code,
and you'll get results. Waxing philosophical about how you believe a
library should behave is not productive.

These silly "Subversion Exception" mails are no help at all, they
provide exactly *zero* information on which anyone can act. And your
refusal to direct TSVN users to TSVN support lists is just bloody
annoying and hence also not productive. If there is a bug in our code,
which of course is possible, we can do exactly nothing about it given
the amount of info we have.


Oh by the way, I doubt this had anything to do with user input, as the
OP states:
> got following exception at trying to start the tortoisesvn Project
> Monitor with a doubleclick on the tray icon.



-- Brane

P.S.: I keep wondering where these crash reports from all the other
Subversion clients out there are going. We don't seem to be seeing (m)any.

Reply all
Reply to author
Forward
0 new messages