Re: Tree conflict detection in 'svn merge'

On Tue, Mar 25, 2008 at 05:38:05PM +0000, Julian Foad wrote:
>> 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"?
>
> When merging textual changes into a file, we already have a merge algorithm
> that succeeds if the target file is "similar enough" to the merge-left
> source that the merge algorithm can find matching hunks of text in it. (I'm
> not sure of the details. I think it has to find the hunks in the correct
> order, and it may require some "context" or "overlap" at the edge of each
> hunk being changed. The details are not important right now.)

OK, I understand that now, thanks. I wasn't aware that there is
already functionality like that. I assumed you were talking about
something that we'd need to implement from scratch.

> When we apply a modify-plus-delete onto an existing target file, my main
> point was that we should not try to see if the textual modification has
> already been done without our knowing it, and ignore that part if so;
> instead, we should assume that the whole requested change is supposed to
> apply cleanly, and if it doesn't then we should signal a conflict. Now, I
> don't know whether we would want to compare the text in this case to
> determine whether we should allow the deletion; that isn't the issue I was
> debating. I'm saying that if we do decide to compare the text, it should be
> strictly the merge-left text that we examine, and not some intermediate
> text that may have existed after merge-left and before the deletion.

Steve and I have managed to implement detection as described in detection.txt
for use cases 4, 5, and 6 over easter, if you haven't noticed yet :)

Check the latest commits to the branch. The implementation is pretty
much to the letter for all use cases, i.e. the basic stuff is done.
I mean to say there is no special-casing [yet].

Steve still had patches from back when he started working on the merge
use cases that turned out to be just about what we wanted. So we got
this done pretty quickly.

Use case 5 detection currently compares text, via svn_diff_file_diff_2 and
svn_diff_contains_diffs. If that needs to be tweaked, I won't object in
any way.

I think we should start filing issues in the svn.tigris.org issue
tracker for the branch now, both to document the progress more
transparently and to keep track of what still needs doing on
the branch.

Karl suggested putting the branch URL into the URL field of the
issues concerning the tree-conflicts branch. This way we can key
the issues by that field (URL contains "tree-conflicts") to tell
them apart from all the others.

I plan to start filing some issues tomorrow, mainly for the failing tests,
and also for some UI issues I'd like to address.

If you have anything you want to file an issue for (e.g. modify+delete?),
please do so.

Stephen Butler is now a partial committer for the tree-conflicts branch,
so you, him, and I can all commit to it. This should help the work flow :)

>> Is the decrease in complexity you mention already covered in detection.txt,
>> with or without your patch?
>
> Yes, the current version of "detection.txt" doesn't say anything about
> needing to follow ancestry for any of the use cases.

I'm glad to hear once again that we really don't need to bother with
ancestry :) :) :)

(I rarely hand out three smilies at once -- I really mean it!)

-- 
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