Stephen Butler wrote:
> Quoting Julian Foad <julianfoad_at_btopenworld.com>:
>
>> Stephen Butler wrote:
>>
>>> Hello tree-conflict fans,
>>>
>>> The first phase of tree conflict detection is available in the tree-
>>> conflicts feature branch. See this post for a recap of the current
>>> functionality implemented by this branch:
>>>
>>> http://svn.haxx.se/dev/archive-2008-01/0296.shtml
>>>
>>> In extending the current tree-conflict-detection scheme to cover
>>> 'svn merge', we want to avoid presenting the user a lot of apparent
>>> tree conflicts that involve files with no common ancestry. To weed
>>> out these false positives, we have to query the repository.
>>
>> Could you elaborate on these "apparent tree conflicts"? I don't know if
>> it's important but I just can't see what you mean by that.
>
> During 'svn update', the state of the working copy is easy to check.
> If any files are out of date (edited or deleted), we mark them as tree
> conflict victims if the update causes a delete-vs-update situation
> (use cases 1 & 2) or a double-delete (use case 3).
>
> During 'svn merge', the history of the working copy's branch is not
> available except through repository queries.
Yes. It's clear that we need to do repository queries, and I would explain that
as "because we need to trace which item in the WC's branch corresponds to a
given item in the original (merge-left) source".
> For use cases 4 & 6,
> where the file has been deleted in the working copy's branch, there's
> no victim in the working copy.
Let's look at use case 4. Change 50 (Foo.c to Foo.c') is being merged onto
urlB. In urlB, Foo.c has already been moved to Bar.c. In the working copy, the
victim is Bar.c. Yes?
I think this may be an example of what I wrote in the other email just now.
Here, as yet I only understand the top-down view of the situation, in which
there is a "victim" file, but you were writing from the point of view of one
particular place in the implementation where the destination file 'Bar.c' is
not known about.
Is that the case?
> If we presume that a tree conflict
> exists, it's likely that the user will be spammed with tree conflict
> warnings about files that never existed in the current branch.
>
> Nobody likes a spammer. :-) On the other hand, the tree conflict
> detection scheme should be simple to explain. I'm afraid the
> current plan is getting rather complicated.
>
>>> ==========
>>> USE CASE 4
>>> ==========
>>>
>>> A file modified in the merge diff does not exist at the current URL.
>>> If a file at the current URL has been deleted in the parent dir's
>>> history, then we might have a tree conflict.
>>>
>>> A tree conflict exists if all of the following predicates are true:
>>>
>>> 1. The merge operation is compatible with tree conflict detection:
>>> We check specific fields of the merge-command baton (of type
>>> merge_cmd_baton_t). If all of the following boolean fields have
>>> the given values, we might have a tree conflict.
>>>
>>> a. (same_repos == TRUE) Both of the source URLs, merge-left and
>>> merge-right, must be in the same repository.
>>
>>
>> That's probably right but I don't understand it.
>>
>> Firstly, the doc string for this field talks about "source" and
>> "target" being in the same repository. Is this what you mean by "source
>> URLs, merge-left and merge-right"? I'm not clear on the terminology.
>
>
> Whoops, my comment was incorrect. The same_repos field is TRUE if the
> source URLs (of the diff) and the target URL (of the working copy) are
> in the same repo. Sorry for the confusion.
>
> Anyway, I think tree conflict detection is still valid only if
> same_repos == TRUE. I.e., only the comment was wrong.
Same sort of difficulty here.
I think being able to correlate source items to target items is the fundamental
criterion for whether we can detect conflicts.
I agree that the source and target must be in the same repository (unless
ancestry is being ignored), but only because we currently have no way to trace
the ancestry across repositories. I don't see why this same_repos condition
flag exists or should be considered independently from asking whether we can
find a common ancestor.
But this seems to be just an implementation detail, so not too important at
this stage.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-02-22 12:58:26 CET