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.
On Tue, Jan 31, 2012 at 9:21 AM, Greg Stein <gstein_at_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, <hwright_at_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
>> 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
Received on 2012-01-31 16:30:51 CET