Re: Account for reflected revisions when performing cyclic merges

On 6/7/07, David James <james@cs.toronto.edu> wrote:
> On 6/7/07, Daniel Rall <dlr@collab.net> wrote:
> > I've got a patch (attached) will implements (a), filtering of
> > reflected revisions. However, Mark Phippard has pointed out that (b),
> > while it potentially causes repeated merges to occur, may be necessary
> > to handle other local mods or conflict resolution which occurred after
> > a merge.
> >
> > So, how do we handle this? Seems like we're stuck with a potential
> > re-merging of an existing set of changes, which is a large part of
> > what merge tracking is attempting to avoid.
>
> Hi Dan,
>
> Here's my understanding of scenario (b):
> 1) User A creates "branch A" from trunk
> 2) User A makes some changes on "branch A"
> 3) User B makes some changes on trunk
> 4) User A merges some changes from trunk to "branch A", resolving conflicts
> 5) User A makes some more changes on "branch A"
> 6) User B makes some more changes on trunk
> 7) User A merges the changes from his branch to trunk
>
> In this scenario, a smart merge algorithm would notice that branch A
> is up to date with trunk as of r3, so we should merge the difference
> between trunk@3 and branchA@5 to trunk in step 7. The user would then
> only be responsible for resolving any conflicts (if any) caused by r6.
>
> Using Subversion, you can already execute the above merge using "svn
> merge trunk@3 branchA@5 trunk". Is it possible to teach our merge
> tracking code to do this automatically?

I made a similar proposal to Dan when we discussed this. There are
even some advantages:

If a user runs svn merge trunk@3 branchA@5 we will not add any
mergeinfo. Which is correct. But if they run svn merge branchA, and
internally we figure out we should do the above merge to implement it,
then we can create mergeinfo.

I did point out that there are still some complications. Suppose the
branch was a long lived feature branch and rather than synch with
trunk, the user only cherry-picked specific revisions that they felt
they needed to resolve. Then it becomes more complicated again
because there is not a single specific revision on trunk you can
compare to.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org