Hi, > Von: Hyrum K Wright [mailto:hy...@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
