This one is public (or at least it will be; writing docs is high on my list this week).
All the existing shim_callbacks (fetch props, fetch base, etc) are only intended for consumers of the shims, and won't be part of any normal code paths. This unlock function is different in that it will eventually be part of a public API. Anybody who wants to receive Ev2 calls may also want to receive information about unlock actions, and this will happen independent of any shims used. If/when we have more such optional callbacks, though, a common baton is the way to go. -Hyrum On Tue, Jan 31, 2012 at 9:21 AM, Greg Stein <gst...@gmail.com> wrote: > Yet another baton? I thought the idea was to have a consolidated > baton, and N callbacks. > > On Tue, Jan 31, 2012 at 09:58, <hwri...@apache.org> wrote: >> Author: hwright >> Date: Tue Jan 31 14:58:38 2012 >> New Revision: 1238645 >> >> URL: http://svn.apache.org/viewvc?rev=1238645&view=rev >> Log: >> Ev2 shims: Introduce a proper callback for the unlocking of files, rather >> than >> using a (technically no-op) deletion of a non-existant property. Right now, >> this all happens in the shims, so external code need not worry about it, but >> eventually callers will need to provide this callback if they are interested >> in such events. >>... -- uberSVN: Apache Subversion Made Easy http://www.uberSVN.com/
