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

Re: svn commit: r984007 - /subversion/trunk/subversion/libsvn_wc/update_editor.c

From: Greg Stein <gstein_at_gmail.com>
Date: Wed, 11 Aug 2010 15:59:05 -0400

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.

Received on 2010-08-11 21:59:44 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.