Gotcha. Thanks for the clarification. (and I just emailed about the role of that callback in the future RA API changes)
On Tue, Jan 31, 2012 at 10:30, Hyrum K Wright <hyrum.wri...@wandisco.com> wrote: > 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/
