Hi everyone, I think that I might have stumbled across an issue with the new tree conflict resolver in case of a delete-vs-delete conflict. Below is a simple PowerShell- based reproduction script that adds a file (r1), removes it (r2), updates to the previous revision, removes the file in the working copy (svn rm), and attempts an update to r2:
rm test -Recurse -Force -ErrorAction Ignore mkdir test svnadmin create test/repo $url = 'file:///{0}/test/repo' -f (pwd) -replace '\\', '/' svn co $url test/wc echo content > test/wc/file.txt svn add test/wc/file.txt svn ci test/wc -m"r1" svn rm test/wc/file.txt svn ci test/wc -m"r2" svn up test/wc -r1 svn rm test/wc/file.txt svn up test/wc svn st test/wc In this case, the tree conflict resolver offers the "Accept incoming deletion" option for file.txt, but choosing it does nothing, and leaves the tree conflict unresolved, which I think is unexpected: > svn up Updating 'test\wc': C test\wc\file.txt At revision 2. Summary of conflicts: Tree conflicts: 1 Searching tree conflict details for 'test\wc\file.txt' in repository: Checking r2... done Tree conflict on 'test\wc\file.txt': File updated from r1 to r2 was deleted by Evgeny.Kotkov in r2. A deleted file was found in the working copy. Select: (p) Postpone, (r) Mark as resolved, (a) Accept incoming deletion, (h) Help, (q) Quit resolution: a Summary of conflicts: Tree conflicts: 1 > svn st ! C test\wc\file.txt > local file delete, incoming file delete or move upon update Summary of conflicts: Tree conflicts: 1 Should I file an issue or add a regression test for this problem? Thanks, Evgeny Kotkov