On Thu, May 5, 2011 at 4:07 AM, Markus Schaber
<m.schaber_at_3s-software.com> wrote:
> Hi,
>
>> Von: Hyrum K Wright [mailto:hyrum_at_hyrumwright.org]
>
>> Historically, notifications were interleaved with the operations, and
>> if a user cancelled during the notification, they cancelled the
>> remaining bits of the operation as well (leaving the wc in some
> possibly funky state).
>> To the user, notification *was* the operation.
>>
>> You've now changed those semantics. Even though a user may cancel in
>> the middle of a set of notifications, they haven't really interrupted
>> the operation. As a result, they may never get a notification for
>> those operations, even thought they were successful, and committed to
> the DB.
>> (The notification items are still pending in the DB, but we've got no
>> way to retrieve them.)
>>
>> We ought to think carefully about introducing this change of behavior.
>
> I fully agree here.
>
> Our code currently relies on the notifications being "lossless", as we
> were told on #svn-dev that this is the way how to find out about
> property changes done by svn operations (update, revert), as prop_time
> is not set any more.
>
> If notifications get unreliable, then we have to maintain our own shadow
> tree of the working copy tree, and compare the properties of all files
> after each operation, just to find out which nodes we have to re-read.
Even if this change is left in, as the API consumer, you don't have
anything to worry about. Cancellation is effected by calling a
consumer-provided callback to see if the operation should cancel, and
as the provider of that function, you can either not provide it
(disallowing the possibility of cancellation) or not cancel within it.
My above concern is more about the command line client than anything else.
-Hyrum
Received on 2011-05-05 14:25:12 CEST