[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

AW: svn commit: r1099657 - in /subversion/trunk/subversion/libsvn_wc: adm_ops.c wc_db.c wc_db.h

From: Markus Schaber <m.schaber_at_3s-software.com>
Date: Thu, 5 May 2011 11:07:01 +0200


> 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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.