On Fri, Apr 09, 2010 at 11:06:57AM -0700, thinkpipes wrote:
> Hello,
>
> --- PROBLEM
> Using the --reintegrate option, merging the same two branches twice
> (from reverting 3 merged files after the first merge) causes many
> non-existent tree conflicts, along with text conflicts, after the
> second merge.
>
> --- DESCRIPTION
> I had to merge branch A into branch B.
>
> So, I checked out B, then ran svn merge --reintegrate A B. This worked well.
>
> However, I didn't want the last 3 check-ins from A to be in B.
>
> So, I ran svn revert on those few files that I didn't want merged in,
> then checked in B back into svn. So far, so good, right?
>
> I then wanted to merge those few files from A back into B. So, I
> checked out B again (which had all of A except for those 3 files), and
> re-ran svn merge --reintegrate A B.
>
> I naturally expected to only see the modification of those 3 files,
That's not quite how it works.
Assuming you have mergeinfo only on your branch roots (as is good
practice):
The mergeinfo on the branch root dictates what will still be merged.
If the mergeinfo says "I have revisions 3-43 from A" it will never
attempt to merge anything from those revisions again.
By reverting the files and committing the mergeinfo on the branch
root, you made these reverts part of the conflict resolution of
your merge commit.
> however I instead got 13 tree conflicts, and 4 text conflicts. Why?
Because you did what's known as a "reflective merge", which Subversion
doesn't handle well.
See http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.reintegratetwice
If this section of the book doesn't help you understand what
you are seeing please feel free to ask more questions.
Stefan
Received on 2010-04-09 23:21:16 CEST