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

Implicit keep-alive after reintegrate merge

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Mon, 9 Jan 2012 11:14:18 +0000 (GMT)

Merging would be simpler if the user didn't have to think about doing the "keep-alive dance" after a reintegrate [1]. I'm trying to teach the sync merge to detect when a reintegrate has been done, so that we could avoid the need for r45 in the following typical sequence: | Rev  Branch Commit |      A   B |-------------------- | r10  X |      | \ | r20  |   X  "New branch B, a copy of A." |      |   | | r30  |   X  "Modify B." |      | / | | r40  X   |  "Reintegrate from B into A." |      | \ | | r45* |   X  "Record-only merge to keep B alive." |      |   | | r50  X   |  "More work in A." |      | \ | | r60  |   X  "Sync from A into B." A patch in progress is attached.  It makes 'merge' detect when one of the revision ranges to be merged would include changes that have already been merged in the opposite direction.  At present it stops the merge, giving a friendly error message.  I would like to make it skip the particular revision(s) and continue to merge all the other revisions in the range, but first we need to get the detection right. Using the above example, if we don't do the r45 record-only merge, then during the last sync merge (which will be committed in r60), the normal merge tracking code first determines that the revision range to be merged is r11-r50 [2].  Then the new code detects that this incoming change brings in new mergeinfo about merges *from* the current target branch B.  Therefore the new code will stop and complain. That's all right for simple cases but it's not good enough. We can say for sure that when we reintegrated B to A (in A:40), that will have added new mergeinfo on A describing merges from B.  However, if change A:40 had instead been a different merge into A, let's say from C, it is still possible that merge might have brought along some new mergeinfo describing merges from B, because of the way mergeinfo is propagated from branch to branch.  Therefore, if we find that change A:40 adds new mergeinfo about merges from B, we cannot simply say that A:40 describes a reintegrate merge from B.  We need to look more closely.  That's what I'm currently working on. Comments? - Julian [1] See the end of <http://wiki.apache.org/subversion/KeepingReintegratedBranchAlive>. [2] Assume HEAD is r50 at this time.

Received on 2012-01-09 12:15:21 CET

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.