On Fri, Aug 11, 2017 at 08:58:46PM +0000, Blaine Whittle wrote: > I'm a big fan of the auto tree conflict resolution feature. > > One optimization I'd like to suggest is after a tree conflict is found, and > if the two branches share ancestry then branch move history search should be > constrained to the start revision of when the branch was made. > > When testing the new conflict resolver, I noticed the file / directory move > search taking upwards of 10-15 seconds while it was reporting searching tens > of thousands of revisions (even though the merge branch was created off the > current working branch 4 or 5 revisions prior.) >
Hi Blaine, It would be nice to have a specific and self-contained test case which triggers this behaviour. But note that, for now, performance is a secondary concern. In my opinion, correctness should be given priority. This is because we are trying to trade the huge amount of time humans now spend on conflict resolution for time which is spent by machines instead. Manual tree conflict resolution is the biggest time sink across SVN's entire user base. I have witnessed merges in corporate environments which took literally days to sort out. So I won't mind if the computer takes a couple of minutes to resolve a conflict, as long as it achieves its task. The resolver operates on a per-node basis. So when it tries to find a related file on a different branch, what matters is the lines of history which can be traced for these specific files. The directory which was copied to create a branch is never under consideration. To learn more about the intended behaviour, see: http://svn.apache.org/repos/asf/subversion/trunk/notes/resolve-moves I believe there will be quite a few implementation bugs still lurking which need to be flushed out during testing. One such bug has already been recorded here: https://issues.apache.org/jira/browse/SVN-4688 Thanks, Stefan
