Branko Čibej wrote on Thu, Nov 08, 2012 at 04:13:52 +0100: > 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.
Should we allow nodes to change their special-ness (namely: whether they have svn:special set, and if yes what's the initial keyword) without a replace? i.e., sure, current clients can do that --- "svn ps svn:special yes COMMITTERS" --- so we'll have to handle that in libsvn_wc. But maybe we shouldn't allow any more instances of that. > I can't see any other way to get consistent behaviour when we > introduce other special file types. > > -- Brane
