On Wed, Aug 11, 2010 at 15:47, Bert Huijben <b...@vmoo.com> wrote: >> -----Original Message----- >> From: Greg Stein [mailto:gst...@gmail.com] >> Sent: woensdag 11 augustus 2010 21:30 >> To: dev@subversion.apache.org >> Subject: Re: svn commit: r984007 - >> /subversion/trunk/subversion/libsvn_wc/update_editor.c >> >> I think you *always* want wq operations to be cancelable. That simply >> means that wq items will be left behind and "svn cleanup" will fix it. >> I see no problem with that. > > The problem here is that once you press ^C all future calls to the global > cancel handler (in svn and other code) return SVN_ERR_CANCELED.. > > So when you press ^C during update, none of the wq operations are handled, > while before we introduced the WQ all loggy operations were just handled. > > So pressing ^C likely locks your working copy in 1.7 (requiring cleanup), > while older versions did not. > (I found this issue when I added some additional tracing to detect where in > ra_serf we leaked these cancel errors)
That seems okay to me. Remember that the cancellation func/baton is also passed (in wq) to things like svn_stream_copy(). That allows for stopping a 5G copy/translation and resuming it later. (and imagine if one/both of the targets is on a network drive!) Removing the callback means the client will be less responsive and may get locked into a very slow, very long operation. We've started passing cancel func/baton through a lot more places in wc, compared to 1.6. That gives us a much more responsive client. I'd like to see that continue, even if it could mean a locked working copy. People should just normally expect ^C to leave a working copy in a locked state. I see no issue with that. Cheers, -g
