[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Subversion Exception!

From: Branko Čibej <brane_at_apache.org>
Date: Thu, 13 Dec 2018 17:26:33 +0100

On 13.12.2018 17:09, Mark Phippard wrote:
>> On Dec 13, 2018, at 10:53 AM, Michael Pilato <cmpilato_at_collab.net> wrote:
>>> On 12/13/18 10:45 AM, Branko Čibej wrote:
>>> Uh. I forgot about the malfunction handler. However this doesn't really
>>> help, other than putting possibly sensitive paths into the crash handler
>>> info? We really shouldn't do it this way, users *will* just copy and
>>> paste the output tot he 'net.
>> Ahem. What Grandpa *meant* to say was:
>> "Oh, cool! So there _is_ a way to report the non-canonical path.
>> Thanks for figuring this out, Julian! Unfortunately, it comes at a
>> cost, namely that of revealing potentially sensitive paths in the output
>> which I strongly suspect will get copied and paste to the 'net. If we
>> could mitigate that part of it, this might turn out to be truly beneficial."
>> ;-)
> Honestly, it seems like complete FUD to me and trying to save face or just be obstinate.
> FWIW, I agree with Stefan on all of this. We should not be doing abort from a library. Whether TSVN could do more to avoid it seems like a separate issue. I do not see why the library cannot just return a useful error and allow the caller to handle it.

Backwards compat dictates that we can't change the signatures of those
functions. We can write new ones with different signatures and deprecate
the old ones.

Or rather "they" because I'm not volunteering for the code churn and
related backporting fallout. That's not stopping anyone else from having
a go.

-- Brane
Received on 2018-12-13 17:26:41 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.