On 08.11.2012 03:19, Philip Martin wrote: > 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?
My first response was going to be, "of course it's a tree conflict', but upon reflection it turns out that view is heavily skewed towards OS and file systems that natively support symlinks, so I'm going to try to rationalize that. :) On one hand, you make a good point that we're basically just looking at file contents and properties. On another hand, semantically, files with "svn:special" set are /not/ files but a different kind of node; what kind precisely depends on the "file contents" but that can be interpreted as an implementation detail. Your example with symlink-symlink conflicts is irrelevant; it's looking at the same node, the kind of the node did not change, therefore it cannot be a tree conflict. I believe that the correct approach would be to always treat a changed node kind (that's either the appearance/disappearance of the svn:symlink property, or a change of the initial keyword in the special-file contents) as if it were a replacement, for the purpose of conflict detection and resolution, even though the node didn't actually get replaced. I can't see any other way to get consistent behaviour when we introduce other special file types. -- Brane
