Perforce: How to integrate across several branches?

I have the following situation of branches in a Perforce repository: There’s a mainline “trunk” and two release branches “1.0” and “1.1”. A branch “customer” with customer specific changes has been branched off the 1.0 branch. Now the customer wants to move to version 1.1. How can I merge the 1.1 branch into the customer branch? The customer specific changes should remain “on top” of 1.1.

Here’s a diagram for one affected file:

1.1                      -(1)---(2)---(3)
                        /           \     \
                       /             \     \
trunk   100--(101)-(102)--103---104---105---106---107
           \
            \
1.0          ---1-----2--...
                 \
                  \
customer           ---1-----2----*3*

The current version of the file I’m looking at is revision 3 on the customer branch.

If I choose to integrate branch “1.1” with target “customer” I would have expected that the common ancestor of both is found (revision 100 on mainline) and all revisions from there leading to the tip of the 1.1 branch are merged (the ones in parentheses).

Instead Perforce only offers to merge revisions 1 to 3 of the 1.1 branch, which fails because it misses the necessary changes that happened on mainline before.

How can I persuade Perforce to do this without having to look at each file manually and selecting the revisions to merge? Maybe the branching strategy is unsuitable? What else sho开发者_Python百科uld I do?

---

When you try to integrate revision 3 from your 1.1 branch, Perforce will only tell you that it's integrating changes on that particular branch -- but revision 1 already contains trunk revisions 101 and 102. When merging, Perforce will identify trunk revision 100 as the common ancestor for conflict resolution.

It's been my experience that the integration you're trying to do should Just Work. Are you seeing changes missing in your integrated source (that can't be explained by improper conflict resolution), or are you just looking at the output of p4 interchanges?

---

I'd strongly suggest trying to merge the customer's changes into the trunk. It's going to continue to be a maintenance nightmare when a few months down the line the customer wants to upgrade to 2.0 + their custom changes.

If you don't want the customer changes reflected in your main project, take the time to restructure the code so that you can expose the customer's desired behavior with a build flag or build configuration file. Have both build configurations running in CI to ensure that future changes don't break the customer's build.

---

To make integrations easy, I would create a specific branches trunk_to_custer and 1.1_to_customer and then issue:

cd customer-workspace
p4 integ -b trunk_to_customer @change-number-at-which-1.1-was-branched
p4 resolve

perhaps an in-between submit here, and then

p4 integ -b 1.1_to_customer 
p4 resolve
p4 submit