Tobias Bading <tbad...@web.de> writes: > However, once I execute "[...]/svn revert -R .", "[...]/svn update", > and "[...]/svn update -r2" in the working copy, the merge works just > fine afterwards. And that "update -r2" is exactly what > no_spurious_conflict in diff_tests.py does before the faulty merge, if > I'm reading the code correctly.
Yes, the test is doing an update to r2. The double update should be an overall no-op, but it is making a difference. You have to compare the working copy before and after the double update and determine what has changed. One would expect the timestamp of 3449_spurious to get changed by the double update, does anything else change? Does the text of 3449_spurious change? Does the output of svn info 3449_spurious change? Does the output of svn pl -v change? Try running sqlite3 .svn/wc.db "select * from nodes order by local_relpath" sqlite3 .svn/wc.db "select * from actual_node order by local_relpath" does anything there change? If you cannot identify what has changed perhaps you could provide a tarball containing the repository and the broken working copy. -- Certified & Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
