There shouldn’t be many cases where the wait is necessary, if any… Resolving a conflict never involves changing BASE and typically we already waited before invoking the resolver. So this could be as simple as just removing the waits. (I can’t really think of a case in tree/property conflicts where this would be needed. Perhaps some hard tree conflict resolve step would be an exception)
I was surprised to see that we have waits… and the functions that have the wait now are probably too low level to have the wait. An invocation of an svn_client api should have just 1 sleep, even on recursive operations. Bert Sent from Mail for Windows 10 From: Stefan Sperling Sent: maandag 15 februari 2016 18:17 To: Bert Huijben Cc: dev@subversion.apache.org Subject: Re: svn commit: r1730546 - in /subversion/trunk/subversion:include/private/svn_wc_private.h libsvn_client/resolved.clibsvn_wc/conflicts.c On Mon, Feb 15, 2016 at 05:30:55PM +0100, Bert Huijben wrote: > Why would you need to wait for timestamps here? > > Can this change the working copy file? > > If it can the wc function should probably return a boolean to notify the case > where it does, and only when it does we should wait for timestamps. > I agree that this should be fixed. I'd like to spend some more time exploring the new APIs before addressing performance issues like this. Hunting down all the code paths where we may or may not modify a working copy file probably takes some time. I'm willing to invest that time eventually, but not right now. Please feel free to fix this yourself. If you don't have time to deal with this problem right away, could you please file an issue so we don't forget? Thanks!