Committed in r1139195. - Julian
On Thu, 2011-06-23, Hyrum K Wright wrote: > On Thu, Jun 23, 2011 at 1:17 PM, Julian Foad <julian.f...@wandisco.com> wrote: > > Greg Stein wrote: > >> Thanks for taking the time to do thus. Only recently did I realize that I > >> named the function incorrectly when I came up with it. In PoCore, I called > >> it pc_error_trace(), for the same reasons you suggested here. > > > > OK, I'll do it. > > > > Does anyone want me to leave "svn_error_return" as an alias for the time > > being, to be removed before 1.7.0, to avoid gratuitous failures with > > developers' local mods and when applying patches over the next few days? > > I'll happily do so if anyone says "yes" (it's very little extra work), > > but if no-one says "yes" then I won't. > > Don't bother leaving the alias. Folks will have to fix it sooner or > later, might as well have them do it sooner. > > >> > There are 695 uses of svn_error_return. > >> > > >> > 681 of them are "return svn_error_return(...);". > >> > > >> > The other 14 are "some_err = svn_error_return(...);". > >> > > >> > So if we're going to change the vast majority of these in any way, what > >> > do folks feel about replacing them with > >> > > >> > SVN_ERR_RETURN(...) > >> > >> No. > >> > >> SVN_ERR() is conditional. Code typically occurs afterwards, and is executed > >> in the non-exceptional case. You're talking about creating a normally-used > >> macro that will hide this control flow change. > > > > OK, good to hear your input. > > Same. I knew there was a reason we didn't use this form when we were > designing this macro, but I just couldn't put my finger on it. > > -Hyrum
