Helix SwarmHelix Swarm
Loading...

br02.html

  • //
  • guest/
  • laura_wingerd/
  • perforce/
  • faq/
  • br02.html #2
  • View
  • Commits
  • Open Download .zip Download (3 KB) 
  1. <html>
  2. <head>
  3. <title>The Branching Papers -- Perforce FAQs</title>
  4. <head>
  5. <body bgcolor=#ffffff>
  6. <font size=-2><b><a href="branching.html#br02">[INDEX]</a></b></font>
  7. <p>
  8. <b>
  9. We tried to integrate a single change from one branch to 
  10. another but in the resolve step we saw hundreds of deltas
  11. that weren't in this change. Why was this?
  12. </b>
  13. <blockquote>
  14. Assume @123 is a changelist that was a bug fix in //depot/6.0.
  15. And assume you used:
  16. <pre>
  17.    p4 integ //depot/6.0/...@123,@123   //depot/6.0.1/...
  18. </pre>
  19. to propagate the bug fix from //depot/6.0 to //depot/6.0.1. 
  20. <p>
  21. Using "@123,@123" as a revision spec in <b>p4 integrate</b> 
  22. is saying "integrate 
  23. from @123 to @123", which limits it to only the deltas associated with
  24. changelist @123.
  25. <p>
  26. However, if this is a "leapfrogging integration" (that is, there are
  27. changelists previous to @123 which are NOT being integrated) then the
  28. <b>p4 resolve</b> step can be confusing unless you know what's happening. 
  29. <p>
  30. The thing you have to look out for is that <b>p4 resolve</b> always uses
  31. the rev previous to the "from rev" to do the 3-way merge.
  32. <p>
  33. I'm sure that didn't make any sense, so here's an illustration. 
  34. Say //depot/6.0.1 is only integrated with //depot/6.0, up as far as @100 
  35. in //depot/6.0. Now you do a 
  36. <pre>
  37.    p4 integ //depot/6.0/...@123,@123   //depot/6.0.1/...
  38. </pre>
  39. Let's see what 
  40. happens to //depot/6.0/foo.c:
  41. <p>
  42. <ul>
  43. <p><li>
  44.     //depot/6.0/foo.c is being integrated into //depot/6.0.1/foo.c
  45.  
  46. <p><li>
  47.     the 'yours' file in the <b>p4 resolve</b> will be //depot/6.0.1/foo.c at
  48.     its current revision on your client
  49.  
  50. <p><li>
  51.     the 'theirs' file in the <b>resolve</b> will be //depot/6.0/foo.c@123
  52.  
  53. <p><li>
  54.     BUT LOOK: the 'base' file will be //depot/6.0/foo.c@122
  55.  
  56. </ul>
  57. <p>
  58. This means that fixes in 6.0/foo.c after @100 and before @123 will appear
  59. as "backing out" diffs in the resolve step. When you look at the
  60. 'diff yours' output, all deltas from @101 to @122 will look like they're
  61. being backed out of the 6.0.1/foo.c file.
  62. <p>
  63. The thing is, even though the diffs LOOK like they're being backed out,
  64. they're not really, because they were never in the 6.0.1/foo.c file to begin
  65. with. But since they're in the base file, you see them in the resolve 
  66. process.
  67. <p>
  68. As long as you expect this, it's not a problem, but most people are 
  69. completely thrown the first time they see it. (That's why I usually try
  70. to discourage shops from doing leapfrogging integrations, but sometimes they
  71. just can't be avoided.)
  72. </blockquote>
  73. <p>
  74. <i>(March 1998)</i>
  75. <p>
  76. <font size=-2><b><a href="branching.html#br02">[INDEX]</a></b></font>
  77.  
  78. <hr>
  79. <h6>This is file $Id: //guest/laura_wingerd/perforce/faq/br02.html#2 $ in the
  80. <a href="http://public.perforce.com/public/index.html">
  81. Perforce Public Depot</a></h6>
  82. </body>
  83. </html>
# Change User Description Committed
#2 85 Laura Wingerd Correct typos and add a few clarifications. 26 years ago
#1 83 Laura Wingerd The Branching Papers. 26 years ago