Re: svn commit: r1238645 - in /subversion/trunk/subversion: libsvn_delta/compat.c libsvn_wc/update_editor.c

[Greg Stein <gs...@gmail.com>]

Yet another baton? I thought the idea was to have a consolidated
baton, and N callbacks.

On Tue, Jan 31, 2012 at 09:58,  <hw...@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.
>...

Re: svn commit: r1238645 - in /subversion/trunk/subversion: libsvn_delta/compat.c libsvn_wc/update_editor.c

[Greg Stein <gs...@gmail.com>]

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 <hy...@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 <gs...@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,  <hw...@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/

Re: svn commit: r1238645 - in /subversion/trunk/subversion: libsvn_delta/compat.c libsvn_wc/update_editor.c

[Hyrum K Wright <hy...@wandisco.com>]

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 <gs...@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,  <hw...@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/