We tried to integrate a single change from one branch to another but in the resolve step we saw hundreds of deltas that weren't in this change. Why was this?
Assume @123 is a changelist that was a bug fix in //depot/6.0. And assume you used:p4 integ //depot/6.0/...@123,@123 //depot/6.0.1/...to propagate the bug fix from //depot/6.0 to //depot/6.0.1.Using "@123,@123" as a revision spec in p4 integrate is saying "integrate from @123 to @123", which limits it to only the deltas associated with changelist @123.
However, if this is a "leapfrogging integration" (that is, there are changelists previous to @123 which are NOT being integrated) then the p4 resolve step can be confusing unless you know what's happening.
The thing you have to look out for is that p4 resolve always uses the rev previous to the "from rev" to do the 3-way merge.
I'm sure that didn't make any sense, so here's an illustration. Say //depot/6.0.1 is only integrated with //depot/6.0, up as far as @100 in //depot/6.0. Now you do a
p4 integ //depot/6.0/...@123,@123 //depot/6.0.1/...Let's see what happens to //depot/6.0/foo.c:
- //depot/6.0/foo.c is being integrated into //depot/6.0.1/foo.c
- the 'yours' file in the p4 resolve will be //depot/6.0.1/foo.c at its current revision on your client
- the 'theirs' file in the resolve will be //depot/6.0/foo.c@123
- BUT LOOK: the 'base' file will be //depot/6.0/foo.c@122
This means that fixes in 6.0/foo.c after @100 and before @123 will appear as "backing out" diffs in the resolve step. When you look at the 'diff yours' output, all deltas from @101 to @122 will look like they're being backed out of the 6.0.1/foo.c file.
The thing is, even though the diffs LOOK like they're being backed out, they're not really, because they were never in the 6.0.1/foo.c file to begin with. But since they're in the base file, you see them in the resolve process.
As long as you expect this, it's not a problem, but most people are completely thrown the first time they see it. (That's why I usually try to discourage shops from doing leapfrogging integrations, but sometimes they just can't be avoided.)
(March 1998)