phi...@apache.org writes: > Author: philip > Date: Wed Nov 7 23:49:06 2012 > New Revision: 1406870 > > URL: http://svn.apache.org/viewvc?rev=1406870&view=rev > Log: > Fix issue 4091, symlink-ness change causes spurious tree-conflict. > > * subversion/libsvn_wc/update_editor.c > (close_file): Only flag symlink-ness conflict if locally modified. > > * subversion/libsvn_wc/wc_db_wcroot.c > (svn_wc__db_wcroot_parse_local_abspath): Only close db if really opened. > > * subversion/tests/cmdline/special_tests.py > (replace_symlinks): Deepcopy the r2 status for later use, remove XFAIL.
I thought this was a simple fix but it turns out to be complicated. Issue 4091 involves a file becoming a symlink, or a symlink becoming a file, without a 'R'eplace, i.e. a text and property change but no delete/add. If the file/symlink is not locally modified then update should simply change the node from one to the other, and that's what the code now does. But if the file/symlink is modified the code raises a tree-conflict and I think that may be a problem. Symlinks are text files in the repository so symlink conflicts are really text-conflicts. If r3 has f -> g and r4 has f -> h and I have local a modification f -> i then an update from r3 to r4 produces a conflict (although the results are not pretty): $ svn st wc C wc/f ? wc/f.mine ? wc/f.r3 ? wc/f.r4 Summary of conflicts: Text conflicts: 1 $ ls -l wc -rw-r--r-- 1 pm pm 13 Nov 8 02:13 f lrwxrwxrwx 1 pm pm 1 Nov 8 02:13 f.mine -> i lrwxrwxrwx 1 pm pm 1 Nov 8 02:13 f.r3 -> g lrwxrwxrwx 1 pm pm 1 Nov 8 02:13 f.r4 -> h The handling of symlink conflicts could be improved, but fundamentally they are text-conflicts. So from an implementation point of view file-symlink conflicts are also text-conflicts. Should we be marking such conflicts as tree-conflicts or text-conflicts? -- Certified & Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
