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
