[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: how issue-2897 branch solves reflective merges?

From: Folker Schamel <schamel23_at_spinor.com>
Date: Fri, 11 Jan 2008 23:49:48 +0100

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

This is an archived mail posted to the Subversion Dev mailing list.