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.
>...
> + * There are a few ways we alter the callback stream. One is when unlocking
> + * paths. To tell a client a path should be unlocked, the server sends a
> + * prop-del for the SVN_PROP_ENTRY_LOCK_TOKEN property. This causes problems,
> + * since the client doesn't have this property in the first place, but the
> + * deletion has side effects (unlike deleting a non-existent regular property
> + * would). To solve this, we introduce *another* function into the API, not
> + * a part of the Ev2 callbacks, but a companion which is used to register
> + * the unlock of a path. See ev2_change_file_prop() for implemenation
> + * details.
> + */
>...
Hey all,
Hyrum and I spoke quite a bit last week about Ev2, and this is one of
the resulting changes. The obvious problem is forcing an "unlock" from
server->client into the old delta editor interface, and what to do in
Ev2. The answer that we came up with was "that is a singular case. it
does not belong in Ev2, but is a special callback for RA when driving
the update/status process."
Thus, the RA interface will eventually change from (delta_editor,) to
(Ev2,unlock_callback). When RA drives the editor, it may sometimes
invoke the unlock callback.
We could not find any other place that performed this funky business
with the locks, so this seemed the best approach.
Thoughts and concerns are welcome, of course.
Cheers,
-g
ps. I've got more ideas and API changes coming. That's for another thread.
Received on 2012-01-31 16:27:32 CET