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

Re: Account for reflected revisions when performing cyclic merges

From: David James <james_at_cs.toronto.edu>
Date: 2007-06-08 01:49:53 CEST

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?



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

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.