Re: Tree conflict detection in 'svn merge'

On Wed, Mar 19, 2008 at 11:11:59PM +0000, Julian Foad wrote:
> If we accept this principle that the basic algorithm should report all such
> conflicts, then some of the complexities that have been mentioned
> disappear. For example, looking at UC5 (rename onto a modified file), we
> wondered about a modified version of this use case in which the
> merge-source included not just a rename but a modification followed by a
> rename. We wondered whether we should try to follow the history of
> Merge-Left (Foo.c) forward in the source branch to find what it looked like
> at the point it was finally deleted. This is unnecessary, as we have no
> reason to want the merge to succeed if the target isn't similar to the
> merge-left source.

I can't recall this discussion properly, I'm afraid.

What do you mean by "the target isn't similar to the merge-left source"?
If you mean a text-comparison, how do you define "similar"?

Is the decrease in complexity you mention already covered in detection.txt,
with or without your patch?

I approve your version of the patch to detection.txt, by the way,
and will commit it. Thanks for improving my wording in several places
by an order of magnitude :)
 
> I expect a similar simplification can be made for UC5, but I haven't done that yet.

You must mean a different use case, because you talked about UC5
above already :)

-- 
Stefan Sperling <stsp_at_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