I have a question concerning intra-branch merging that someone may be
able to help me with. I'll explain what I was trying to do:
I had a trunk, and two branches from that trunk, b1 and b2. Work was
occurring simultaneously on b1 and b2, and I needed a new component that
had been created on b1 while I was working on b2. I cherrypick merged
each of the changes for that component from b1 directly to b2 and so b2
had the following mergeinfo:
I did not merge these changes to trunk because our QA procedure only
allows changes to be merged back to trunk after they have been reviewed,
and nobody was able to review it at the time.
Then, later on, b1 was ready to be merged back to trunk, so I did the
reintegrate merge of b1 to trunk. Then I tried to merge trunk to b2 to
get the latest changes from trunk, and got a tree conflict for that
directory that I had cherrypick merged directly from b1. The conflict
was "local add, incoming add upon merge", and I understand this to mean
that the directory already exists in the working copy and it was also
created in one of the incoming changes. I resolved the conflict manually
and checked b2 back in. The mergeinfo for b2 ended up being:
/branches/b1_oldname/dev:32494-33857 (this branch got renamed at some point)
/trunk/dev:34459-35602 (34459 was the revision that b2 was branched off
of trunk, 35602 was the merge of b1 to trunk)
I had thought that SVN would be able to determine that it should not
re-apply the changes creating the component because of the stored
mergeinfo. I know that it would work if both merges had been between the
What confuses me more is that the mergeinfo now shows that all of b1 has
been merged to b2 (not just the changes I had cherrypicked), and that
trunk has been merged too. Yet it did not try to apply every change
twice. It seems like SVN can tell not to apply changes twice in some
situations but not others.
Is intra-branch merging a recipe for tree conflicts down the road?
Should it be avoided? Or am I doing something really braindead?
Thanks for any insight you can give me. Happy to provide more info if
Received on 2010-08-03 11:28:52 CEST