Re: simple tree conflict detection

On Tue, Nov 13, 2007 at 08:51:39AM -0500, C. Michael Pilato wrote:
> > Running 'svn resolved' on the victim will cause the working-conflict-file
> > to be refreshed, removing the victim's conflict description.
>
> Suggest saying "removed" instead of "refreshed" here. That *is* what you
> mean, right?

We mean refreshed.

If there are more than one, say 3, tree conflicts rooted at a directory,
then we need to keep the working-conflict-file until *all* 3 conflicts
are resolved.

So deleting the entire file whenever the user runs svn resolved <victim>
won't do if there are other tree conflict victims in the directory.

We only delete the file if the last tree conflict is declared as resolved.

> > static struct svn_wc__tree_conflict_human_readable_phrases phrases = {
> > "The update wants to delete the file '%s'\n"
> > "(possibly as part of a rename operation)"\n,
> > "The update wants to edit the file '%s'\n",
> > "The merge wants to delete the file '%s'\n"
> > "(possibly as part of a rename operation)"\n,
> > "The merge wants to edit the file '%s'\n",
> > "but you have deleted it locally. Maybe you renamed it?\n",
> > "but you have edited it locally.\n",
> > "but it does not exist locally. Maybe you renamed it?\n"
> > };
>
> I'm not sure if this sort of make-a-sentence-from-parts stuff is permissable
> under our localization guidelines. But I suspect that you don't require
> that these strings be treated as sentence fragments anyway -- if they each
> accept the '%s' formatting token, they could each be full sentences:
>
> The update wants to delete the file 'foo'.
> You have deleted 'foo' locally. Maybe you renamed it?

Yes, that's definitely easier to translate.
Thanks for pointing this out.
 
> > Currently we plan to detect use cases 1 to 3 at the following points
> > in the code:
> >
> > libsvn_wc/update_editor.c, open_file():
> >
> > If the file is scheduled for deletion, we have a tree conflict.
> > This is use case 1 described in the paper attached to issue #2282
> >
> > libsvn_wc/update_editor.c, do_entry_deletion():
> >
> > If we are about to delete a path that has local mods,
> > mark the containing directory as tree conflicted.
> > This is tree conflict use case 2 as described in the
> > paper attached to issue #2282.
> >
> > If we are about to delete a path that has been scheduled
> > for deletion, mark the containing directory as tree conflicted.
> > This _could_ be tree conflict use case 3 as described in the
> > paper attached to issue #2282. Proper detection would require
> > true renames.
>
> Looks good so far, Stephen.

What I am a bit worried about is that the use case detection
is fairly broad.

See how we try to detect use case 3, for example -- the check will
also be triggered if an update and the user both delete the same file!

I think I can hear people who want subversion to merge conflicts
automatically as much as possible grind their teeth at this point...

But we cannot use a smaller net to catch our fish at the moment.
Improving the detection further would require true rename tracking
in either the working copy or on the server side or both, depending
on the use case.

I hope people won't mind having to "resolve" a "conflict" caused
by a concurrent delete. It is not a conflict in my opinion either,
but we cannot avoid flagging it as one with the way renames are
currently [not] implemented.

-- 
Stefan Sperling <stsp@elego.de>                 Software Developer
elego Software Solutions GmbH                            HRB 77719
Gustav-Meyer-Allee 25, Gebaeude 12        Tel:  +49 30 23 45 86 96 
13355 Berlin                              Fax:  +49 30 23 45 86 95
http://www.elego.de                 Geschaeftsfuehrer: Olaf Wagner