On 08.11.2012 03:19, Philip Martin wrote:
> 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?
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
Received on 2012-11-08 04:14:34 CET