Hi Kamesh!
To summarize what 2897 can and what it cannot do:
a) 2897 is better than svnmerge, because,
when merging feature-branch back into trunk,
then it is able to correctly handle manual changes
which were committed together with merges
from trunk into feature-branch.
b) But when you have resolved conflicts when merging trunk into
feature-branch, then you have to do that conflict resolution again
when merging feature-trunk back to trunk
(except for the special case you mentioned "accepting MINE").
Is this correct?
Some additional comments below:
> Hi Folker,
>
> ...
>
> >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.
It is possible. By doing suitable patch arithmetics.
(For example by the algorithm which I posted some time ago.)
But of course, this does not mean that it must be supported
in the next subversion release.
> >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.
Yes, but this is only a simplified technical sample.
In real world, "a", "b", "aa" etc. represent overlapping
multi-line code blocks.
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 23:50:04 CET