Branko Čibej wrote on Thu, Nov 08, 2012 at 04:13:52 +0100:
> 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.
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
Received on 2012-11-08 05:26:59 CET