Hi Folker,
>> We are not applying the r17, sorry if I worded it that way. Following
>> example should make this case clear.
>>
>> Consider the case
>> a. /trunk/test.c = 'line1\nline2\nline3'
>>
>> b. Create feature branch /feature_branch from /trunk
>>
>>
>> c. Modify /trunk/test.c line1 -> tline1 at r13
>>
>>
>> d. Modify /trunk/test.c line2 -> tline2 at r17
>>
>> e. Modify /trunk/test.c line3 -> tline3 at r29
>>
>> f. Modify /feature_branch/test.c line2 ->fbline2 commit at r30.
>>
>> g. merge /trunk r13 to /feature_branch working copy. NO COMMIT
>>
>> h. merge /trunk r17 to /feature_branch working copy. This would give
>> raise to a conflict resolve it by 'line2' being 'RESOLVED_LINE2'. NO COMMIT
>>
>> i. merge /trunk r29 to /feature_branch working copy. COMMIT at r40
>> (Reflective revision)
>>
>> j. merge /feature_branch to /trunk working copy.
>>
>> r40 is merged with reflective call back.
>>
>> reflective_merge_file_changed(mine, older, yours)
>>
>> mine = 'tline1\ntline2\ntline3'
>> older = 'line1\nfbline2\nline3'
>> yours = 'tline1\nRESOLVED_LINE2\ntline3'
>>
>>
>> After merging r13 older='tline1\nfbline2\nline3'
>> After merging r29 older='tline1\nfbline2\ntline3'
>>
>> diff(older, yours) = "@@ -1,3 +1,3 @@
>> tline1
>> -fbline2
>> +RESOLVED_LINE2
>> tline3"
>>
>> Which would give raise to a conflict as trunk does not have 'fbline2'.
>In other words, Case3 results in a conflict?
Yes.
>In other words, if you merge changes from trunk into a feature branch
>causing conflicts, and you have resolved these conflicts,
>then you again have to resolve conflicts
>when merging the feature branch back to trunk?
Yes. But not always, In one special case conflict is not bi-directional.
That special case 'Resolving conflict by accepting MINE changes'.
In other words this algorithm reduces the conflict not eliminate it fully which is impossible.
>Regarding your overall approach,
>is is my following analysis correct?
>Your current approach indirectly implements patch arithmetic
>(merging changes into OLDER effectively means substracting
>changes for the final merge) as required for solving the issues, right?
Yes.
>However, since you don't care about the order of operations
>in that "patch arithmetic" (and patch algebra obviously is non-commutative),
>the limitation is that the user get problems if changes overlap
>(as for example when merging from trunk to feature-branch
>and resolving conflicts), right?
Yes.
>As consequence, it cannot handle the following scenario, right?
>- Trunk has one file containing just one line "a".
>- Branch is created from trunk.
>- Branch changes manually "a" to "aa" and commits.
>- Trunk changes manually "a" to "b" and commits.
>- Trunk is merged (with merge-tracking, "a" -> "b") into branch (currently: "aa").
>This gives a conflict. The conflict is resolved manually as "bb" and committed.
>- Trunk changes manually "b" to "c" and commits.
>- Trunk is merged (with merge-tracking, "b" -> "c") into branch (currently: "bb").
>This gives a conflict. The conflict is resolved manually as "cc" and committed.
>- Now we merge branch into a trunk wc.
>Obviously the overall result of all these merges should be "cc",
>since the feature branch is up-to-date with all work of trunk.
>(This is scenario
>http://svn.haxx.se/dev/archive-2007-12/0134.shtml
>but without assuming implicit commits.)
What you say is correct. But our textual merge is always line based not character based.
>(My post is not meant as critics. I know that merge-tracking is hard.
>I just want to understand what is supported and what not.)
You are welcome. I always liked your meticulous posts.
Thanks
With regards
Kamesh Jayachandran
Received on 2008-01-11 20:33:42 CET