RE: svn commit: r1730546 - in /subversion/trunk/subversion:include/private/svn_wc_private.h libsvn_client/resolved.clibsvn_wc/conflicts.c

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_at_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!
Received on 2016-02-15 23:31:32 CET