philip_at_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
Received on 2012-11-08 03:27:20 CET