Loading...
Helix SwarmHelix Swarm
Loading...

br03.html

  • //
  • guest/
  • hari_krishna_dara/
  • perforce/
  • faq/
  • br03.html #1
  • View
  • Commits
  • Open Download .zip Download (6 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#br03">[INDEX]</a></b></font>
  7. <p>
  8. <b>
  9.     I have a file I renamed in one branch. When I try to integrate
  10.     changes from that branch to another, Perforce insists on renaming
  11.     the same file in the target branch. How do I prevent that?
  12. </b> 
  13. <p>
  14. <blockquote>
  15. I think part of the problem is that people assume <b>p4 integrate</b> is
  16. doing something other than what they've told it to do.  Perforce has no
  17. alternative but to obey the commands you give it.  The key is to use
  18. branch views with correct file patterns for integration.
  19. <p>
  20. I'll try to explain how it works, starting with some background first 
  21. -- I never really know how much people understand about this stuff, so 
  22. forgive me if I start at too remedial a level.  Please bear with me while 
  23. I try to explain without being able to wave my arms around or scribble on 
  24. a cocktail napkin.
  25. <p>
  26. For example, take the codeline //depot/A. You know you can branch that
  27. into //depot/B using:
  28. <pre>
  29. 	p4 integ //depot/A/... //depot/B/...
  30. 	p4 submit
  31. </pre>
  32. This takes every single file in the //depot/A path and makes a copy
  33. of it in the //depot/B path. Furthermore, given a file like:
  34. <pre>
  35. 	//depot/A/foo.c#14
  36. </pre>
  37. Perforce stores the fact that revisions #1 thru #14 of //depot/A/foo.c have
  38. been integrated into //depot/B/foo.c. So if you try the same integrate
  39. on that file again:
  40. <pre>
  41. 	p4 integ //depot/A/foo.c //depot/B/foo.c
  42. </pre>
  43. Perforce will tell you "all revisions already integrated" (unless of course
  44. there's a newer version of foo.c in //depot/A.)  That's because it looked
  45. at all the files in the "//depot/A/foo.c" pattern and checked each one's
  46. integration records relative to its counterpart in the files listed in the
  47. "//depot/B/foo.c" pattern. In this case, there is only one file listed
  48. by each pattern. But the same thing happens if you try to integrate
  49. the whole codeline:
  50. <pre>
  51. 	p4 integ //depot/A/... //depot/B/...
  52. </pre>
  53. Perforce takes every file in the "//depot/A/..." pattern
  54. and checks its integration records
  55. relative to the file that matches it in the "//depot/B/..." pattern. 
  56. <p>
  57. SO...all that was just the opening act. Here comes the plot. 
  58. <p>
  59. You know you can rename //depot/A/foo.c thus:
  60. <pre>
  61. 	p4 integ //depot/A/foo.c //depot/A/bar.c
  62. 	p4 delete //depot/A/foo.c
  63. 	p4 submit
  64. </pre>
  65. Perforce has done the whole ball of wax for the foo.c->bar.c
  66. integration: it's made a copy of foo.c in bar.c, and it's recorded the
  67. fact that all revisions of foo.c have been integrated into bar.c. 
  68. <p>
  69. But none of that matters, because no one is going to be doing any more
  70. integrations from foo.c into bar.c.  From now on, users who sync to
  71. //depot/A will get bar.c, not foo.c.  The don't care (and may not even
  72. know) that foo.c ever existed.  If they do care, they can always use
  73. commands like "p4 filelog bar.c" and "p4 changes -i bar.c" to see the
  74. origin and evolution of bar.c.
  75. <p>
  76. Okay, so say later you want to propagate the latest batch of changes
  77. from //depot/A to //depot/B. You use the commands:
  78. <pre>
  79. 	p4 integrate //depot/A/... //depot/B/...
  80. 	p4 resolve
  81. 	p4 submit
  82. </pre>
  83. The <i>intent</i> of this <b>p4 integrate</b> 
  84. command is correct, but because of the
  85. rename that occured in //depot/A, the <i>effect</i> may not be.  The effect,
  86. of course, is that when Perforce concocts the list of files in the
  87. "//depot/A/..." pattern, it comes up with foo.c#15 and bar.c#1.  When it
  88. checks foo.c's integration records, it finds that only revs #1 thru #14
  89. have been integrated into the file that matches it in the target
  90. pattern.  So it does the action to integrate foo.c#15, which is to
  91. delete //depot/B/foo.c.  Likewise, for //depot/A/bar.c#1, it finds there
  92. is no matching file in "//depot/B/..." pattern, so it adds it.
  93. <p>
  94. Whoa --- you've just propagated a rename from one branch to another!
  95. Was that what you wanted?  No?  Well, the integrate command was only
  96. doing what you told it to do.  The command shown above is the "integrate
  97. everything including renames" command.
  98. <p>
  99. If you want to rename files in one branch, but not in another branch,
  100. and if you want to be able to propagate changes between files whose
  101. names are not the same, the key is to give <b>integrate</b> the correct file
  102. patterns to look at when it compares integration records.
  103. <p>
  104. When you're doing integrations across codelines whose filenames match
  105. exactly, it's easy to put the branch view right on the <b>integrate</b>
  106. command lines, as shown above.  But once filenames no longer match, you
  107. can't tell <b>integrate</b> to use patterns that <i>do</i> expect them to match.
  108. Here's where stored branch specs are indispensible.
  109. <p>
  110. The command 
  111. <pre>
  112. 	p4 integrate //depot/A/... //depot/B/...
  113. </pre>
  114. is exactly the same as:
  115. <pre>
  116. 	p4 integrate -b AtoB
  117. </pre>
  118. where "AtoB" is a stored branch spec whose view is defined thus:
  119. <pre>
  120. 	View:
  121. 		//depot/A/...    //depot/B/...
  122. </pre>
  123. However, now that you've got filenames that don't match between those
  124. patterns, you need to modify the branch view to accomodate the mismatches:
  125. <pre>
  126. 	View:
  127. 		//depot/A/...      //depot/B/...
  128. 		//depot/A/bar.c    //depot/B/foo.c
  129. </pre>
  130. A stored branch view can have any number of mapping lines. Each line
  131. overrides any before it. So the spec above now defines how the matching
  132. will be done: all the files in //depot/A will be matched with files of
  133. the same name in //depot/B, <i>except</i> for //depot/A/foo.c, which will be
  134. matched with //depot/B/bar.c. Now, to propagate changes from
  135. //depot/A to //depot/B, while preserving the original filenames in 
  136. //depot/B, you'd use:
  137. <pre>
  138. 	p4 integ -b AtoB
  139. 	p4 resolve 
  140. 	p4 submit
  141. </pre>
  142. <p>
  143. As of Rel 99.1, branch specs can be used
  144. for diffing as well as integrating. So you could use:
  145. <pre>
  146. 	p4 diff2 -b AtoB
  147. </pre>
  148. and one of the outputs would be the diffs between //depot/A/bar.c and
  149. //depot/B/foo.c.
  150. <p>
  151. </blockquote>
  152. <p>
  153. <i>(February 1999)</i>
  154. <p>
  155. <font size=-2><b><a href="branching.html#br03">[INDEX]</a></b></font>
  156.  
  157.  
  158. <hr>
  159. <h6>This is file $Id: //guest/hari_krishna_dara/perforce/faq/br03.html#1 $ in the
  160. <a href="http://public.perforce.com/public/index.html">
  161. Perforce Public Depot</a></h6>
  162. </body>
  163. </html>
# Change User Description Committed
#1 5093 Hari Krishna Dara Populating perforce branch.
I will be adding p4admin files to it. 		20 years ago
//public/perforce/faq/br03.html
#1 112 Laura Wingerd Publish "Branching FAQ"
(pull in changes from //guest/laura_wingerd/perforce/faq/... ) 		26 years ago
//guest/laura_wingerd/perforce/faq/br03.html
#2 88 Laura Wingerd fix typo 26 years ago
#1 83 Laura Wingerd The Branching Papers. 26 years ago