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.
Best regards,
Markus Schaber
Received on 2011-05-05 11:07:35 CEST