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?
Cheers,
David
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jun 8 01:50:03 2007