> On Dec 13, 2018, at 11:26 AM, Branko Čibej <br...@apache.org> wrote: > > On 13.12.2018 17:09, Mark Phippard wrote: >>> On Dec 13, 2018, at 10:53 AM, Michael Pilato <cmpil...@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. >
Fair enough. I have largely stayed out of the conversation for the same reason ... I am not offering to help with the effort. It is good to hear you are not necessarily opposed to someone doing this work because I was under the impression you would try to block those changes. Mark
