On Wed, Aug 11, 2010 at 15:47, Bert Huijben <bert_at_vmoo.com> wrote:
>> -----Original Message-----
>> From: Greg Stein [mailto:gstein_at_gmail.com]
>> Sent: woensdag 11 augustus 2010 21:30
>> To: dev_at_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
Received on 2010-08-11 21:59:44 CEST