Helix SwarmHelix Swarm

br11.html

  • //
  • guest/
  • laura_wingerd/
  • perforce/
  • faq/
  • br11.html #2
  • View
  • Commits
  • Open Download .zip Download (7 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#br11">[INDEX]</a></b></font>
  7. <p>
  8. <b>
  9. I read through the manual about branching, but I just can't figure out
  10. how to apply it to our daily build procedures here. 
  11. Our old SCM system has a completely different branching model.
  12. How do I set up our builds to work with Perforce? <i>[Detailed build
  13. description abridged.]</i>
  14. </b>
  15. <blockquote>
  16. Perforce approaches branching completely differently than other systems.
  17. It's very easy to use once you understand it, but most of our customers start
  18. out asking questions exactly like this. 
  19. <p>
  20. From your description, it sounds like development is so fast-paced that
  21. by the time a daily build is done, the project has evolved considerably,
  22. so files the build engineer may have checked out and changed are no longer
  23. at the head revisions. Thus the only way to label a buildable set of files
  24. is for the build engineer to check his changes in on a branch.
  25. <p>
  26. Say your project code is stored in the //depot/main path.
  27. Developers all submit their changes directly into that path. They are
  28. using client workspaces with views like:
  29. <pre>        
  30. 	//depot/main/...  //my_client/main/...
  31. </pre>
  32. I'd create a build branch right off -- call it //depot/mainbuild, for
  33. example. It will be a mirror of the mainline, but the build engineer has 
  34. total control over changes that affect it.
  35. <p>
  36. To create //depot/mainbuild, first make sure the client workspace you use
  37. for the builds has both branches in its view. Say your client is
  38. "my_build_client" -- the client spec should look something like:
  39. <pre>
  40.         Client: my_build_client
  41.         Root:   c:\ws
  42.         View:
  43.                 //depot/main/...  //my_build_client/main/...
  44.                 //depot/mainbuild/...  //my_build_client/mainbuild/...
  45. </pre>
  46. Then, using the build client workspace, use "integrate" to branch the depot
  47. files.  (I'll show you the p4 commands here -- if you're using P4Win,
  48. you can look up the operations in the "P4 to P4Win Translation Guide".)
  49. <pre>
  50. 	p4 integ -v //depot/main/... //depot/mainbuild/...
  51. 	p4 submit
  52. </pre>
  53. This creates the "//depot/mainbuild" files in the depot.  (Note that 
  54. "lazy copies" are made -- the files aren't actually duplicated.) 
  55. In your workspace, the //depot/mainbuild files will be put
  56. in your c:\ws\mainbuild directory.  That's the directory you will use
  57. for your builds.
  58. <p>
  59. After you've set up your build branch, you can implement your 
  60. automated build process. What it should do is this:
  61. <p>
  62. <ol>
  63. <p><li>
  64.            Get the number of the latest changelist submitted into
  65.            //depot/main:
  66. <pre>
  67. 	p4 changes -m1 //depot/main/...
  68. </pre>
  69.            For demonstration purposes, let's say that changelist 
  70.            number is "1001".
  71.  
  72. <p><li>
  73.            Integrate the main changes into mainbuild, so you can build
  74.            with everything up to and including changelist 1001:
  75. <pre>
  76. 	p4 sync //depot/mainbuild/...
  77. 	p4 integ //depot/main/...@1001 //depot/mainbuild/...
  78. 	p4 resolve -at
  79. 	p4 submit
  80. </pre>
  81.            Assume this submit creates changelist 1015.
  82.  
  83. <p><li>
  84.            Do a build. Find out what's wrong, and fix the files:
  85. <pre>
  86. 	<small><i>(...build...)</i></small>
  87.  
  88. 	p4 edit c:\ws\mainbuild\complex.h  c:\ws\mainbuild\problem.c
  89.  
  90. 	<small><i>(...fix complex.h and problem.c...rebuild, refix, rebuild...)</i></small>
  91.  
  92. 	p4 submit
  93. </pre>
  94.            Assume the last submit you did to get a good build 
  95.            created changelist 1019.
  96.  
  97. <p><li>
  98.            Once your build is good, you can explicitly label the files, or
  99.            you can simply use the number of last changelist submitted into 
  100.            mainbuild as a label. 
  101.  
  102.            To create a label takes two steps -- first you create the label
  103.            spec, then you apply (sync) the files to the label.
  104.  
  105.            To create a spec for an explicit label called "good_build":
  106. <pre>
  107. 	p4 label good_build
  108. </pre>
  109.            This brings up an editor form. Set up the label view thus:
  110. <pre>
  111. 	View:
  112. 		//depot/mainbuild/...
  113. </pre>
  114.            To apply the files to the label:
  115. <pre>
  116. 	p4 labelsync -l good_build //depot/mainbuild/...
  117. </pre>
  118.            However, the set of files labelled by "good_build" is exactly 
  119.            the same as the set of files identified by
  120.            "//depot/mainbuild/...@1019", so you may not need to create a
  121.            label at all, depending on what you use it for.
  122.  
  123. <p><li>
  124.             In order for developers to see the build change you had to make, you
  125.            have to integrate from //depot/mainbuild back into
  126.            //depot/main.  Still using your build client workspace,
  127.            here's how you do it:
  128. <pre>
  129. 	p4 sync //depot/main/...  
  130. 	p4 integ //depot/mainbuild/...  //depot/main/...
  131. </pre>
  132.                   The files you had to change in order to get a good
  133.                   build are now opened in your workspace and scheduled for
  134.                   resolve.  I always like to do the resolve in two steps:
  135. <pre>
  136. 	p4 resolve -as
  137. </pre>
  138.                   This automatically resolves files which have not been
  139.                   changed by developers since you did the build.  Any
  140.                   remaining unresolved files are ones you changed <i>and</i>
  141.                   developers changed.  So you have to resolve them
  142.                   manually so that nobody's changes get lost:
  143. <pre>
  144. 	p4 resolve
  145. </pre>
  146.                   This puts you in the resolve program, where you can
  147.                   see diffs, edit conflicts, and choose the result you want.
  148. <pre>
  149. 	p4 submit
  150. </pre>
  151.            Now, developers who want to update their workspaces can simply
  152.            sync to pick up your changes.
  153.  
  154. </ol>
  155.  
  156. <p>
  157. As an aside, let me point out some reporting commands that give
  158. you information about the state of your depot. You may find a need
  159. for these in your automated build process.
  160. <ul>
  161. <p><li>
  162.   Before integrating your build fixes back into //depot/main, you can 
  163.   list all the changelists submitted by developers <i>since</i> you did
  164.   your build. The highest changelist you built with is 1001, so use 1002 as
  165.   the threshold:
  166. <pre>
  167.      p4 changes //depot/main/...@1002,#head
  168. </pre>
  169. <p><li>
  170.   You can list the affected files with: 
  171. <pre>
  172.      p4 files //depot/main/...@1002,#head
  173. </pre>
  174. <p><li>
  175.   And you can show the diffs with:
  176. <pre>
  177.      p4 diff2 //depot/main/...@1001 //depot/main/...#head
  178. </pre>
  179. <p><li>
  180.   Similarly, here's how to list the changelists, files, and diffs for the
  181.   changes <i>you</i> had to make to get a good build:
  182. <pre>
  183.      p4 changes //depot/mainbuild/...@1016,#head
  184.      p4 files //depot/mainbuild/...@1016,#head
  185.      p4 diff2 //depot/mainbuild/...@1015 //depot/mainbuild/...#head
  186. </pre>
  187.  
  188. <p>
  189. Hope this helps -- sorry for the verboseness.
  190.  
  191. </blockquote>
  192. <p>
  193. <i>(September 1998)</i>
  194. <p>
  195. <font size=-2><b><a href="branching.html#br11">[INDEX]</a></b></font>
  196.  
  197. <hr>
  198. <h6>This is file $Id: //guest/laura_wingerd/perforce/faq/br11.html#2 $ in the 
  199. <a href="http://public.perforce.com/public/index.html">Perforce Public Depot</a></h6>
  200. </body>
  201. </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