On Tuesday 06 March 2007 14:55, Mark Phippard wrote:
...
> Problem to Solve
>
> In the above scenario, when each pass of the merge runs it is possible that
> one or more conflicts are created from the merge. If any conflicts are
> created, then merge can finish the current pass it is performing, but it
> cannot continue on to do the next pass unless those conflicts are resolved.
...
> So what other solutions exist? ... My
> solution would be to perform the merge in one pass. Somehow, we would have
> to collapse all of the revisions being merged into something that can be
> expressed as a single diff. ...
Sorry for coming in without having *any* level of competence.
I just want to share a bit of brainstorming - maybe someone can make something
useful out of my ramblings.
Imagine we have trunk copied to branch in r7, and going forward to r30.
User merged r9 and r20 into his branch, as r14 and r25, and did other changes
as r11 and r27.
He now wants to get the other changes from trunk, too.
Using the "traditional" model we'd have to merge r8, r10:r19 and r21:r30 from
trunk to branch - which could make conflicts that would possibly be removed
by later commits, etc.
How about reversing that. We know that we left trunk at 7, and want to join at
30 again. The only changes that didn't come from trunk are r11 and r27; so we
simply take the trunk at 30, and try to apply r11 and r27.
This is O(Nr. of changes by user), and not O(Nr. of changes on trunk).
If the user merged from other branches too, these are "user"-changes, unless
we happen to find the branch had been merged from trunk lately - then we take
the other branch as merge "source", and apply the user- and few trunk-changes
to it.
So we try to find the latest revision matching most of our target, and apply
only the missing pieces.
(We "reuse" merge operations that happened before, and take the one that we
like as base.)
I don't know which problems that might make - but maybe it's an idea.
Regards,
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 7 13:58:01 2007