Hi Kamesh!
>>> Case3:
>>>
>>> We merge -r13, -r17(conflicting), -r29 from /trunk to /feature_branch
>>> + local non-conflicting change + conflict resolution to r17 to
>>> /feature_branch/test.c and commit at r40
>>> (Assume this is the only synch up)
>>>
>>> Now we merge /feature_branch -r1:40 back to /trunk.
>>>
>>> It does a merge of -r1:39 which is a normal merge.
>>> It does a reflective merge of 40.
>>> Let us say /feature_branch/test.c got a change from a merge at
>>> r40(Our first merge)
>>>
>>> To calculate the *meaningful diff*, We apply -r13 change to OLDER,
>>> and r29 change to OLDER. (SEE WE DONT APPLY r17 as it is a
>>> conflicting one)/
>>>
>>> Now in this case after the above 2 merges(r13, r29) OLDER becomes
>>> (YOURS-local non conflicting changes - r17 - conflict resolution to
>>> r17) and hence
>>> (YOURS-YOURS +local non conflicting changes + r17 + conflict
>>> resolution to r17) is applied to MINE. i.e local non conflicting
>>> changes + r17 + conflict resolution to r17.
>>
>> Isn't r17 already contained in MINE and now applied again?
>>
>> Cheers,
>> 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?
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?
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?
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?
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.)
(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.)
Cheers,
Folker
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-01-11 17:52:21 CET