On 13.12.2018 17:39, Mark Phippard wrote: >> 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.
I never said that it's a good idea to abort in a library. We made a mistake in the early days of this project to allow such patterns. I am quite angry at the contrariness and stubbornness of one TSVN developer, who is *also* a Subversion PMC member. He could have proposed changes or fixed those functions years ago. Instead its always "you should fix this" and "you should fix that", when it's his project, too. WTF? Am I the only one who finds this to be really bad form? -- Brane
