subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bert Huijben <b...@qqmail.nl>
Subject RE: svn commit: r1730546 - in /subversion/trunk/subversion:include/private/svn_wc_private.h libsvn_client/resolved.clibsvn_wc/conflicts.c
Date Mon, 15 Feb 2016 22:31:22 GMT
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!


Mime
View raw message