Hello all, I just got bitten by what looks like a bug in the handling of tree conflicts involving replaced files. To demonstrate: User A replaces foo.txt and commits their change: $ svn st -v R 4 4 abuchanan foo.txt $ svn commit -m 'replacing foo' Replacing foo.txt
User B has modified foo.txt and gets a tree conflict when they svn up: $ svn up C foo.txt At revision 5. Summary of conflicts: Tree conflicts: 1 $ svn st -v A + C - 4 abuchanan foo.txt > local edit, incoming delete upon update Knowing that their modifications can be discarded, user B tries to get things on track by reverting foo.txt. ***This results in their local foo.txt no longer being versioned and their working directory "forgetting" about the incoming replacement.*** $ svn revert foo.txt Reverted 'foo.txt' $ svn st -v 5 5 abuchanan . ? foo.txt $ svn up At revision 5. $ svn st -v 5 5 abuchanan . ? foo.txt $ foo.txt is in the repository, but svn up doesn't grab it. Deleting the now unversioned copy and running svn up with foo.txt as the explicit target will correctly check it out, but it can be hard to realize that something's missing when svn st and svn up of that directory say that everything's up to date. Thanks, -Andrew