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.wright_at_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 <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
>>> 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/
Received on 2012-01-31 16:32:35 CET