<html> <head> <title>The Branching Papers -- Perforce FAQs</title> <head> <body bgcolor=#ffffff> <font size=-2><b><a href="branching.html#br09">[INDEX]</a></b></font> <p> <b> We've got three related codelines we'd like to set up in Perforce, but our current SCM system is so hopeless we don't have any branch or integration history to convert. How can we make these three separate directory trees into related Perforce branches? Also, which Perforce commands would we use to exercise this acceptance test ... <i>[gory details elided]</i>. </b> <blockquote> <p> First, my assumptions. You have: <pre> M=/home/Master # The last known good source V1=/home/v1root # Variant 1 tree V2=/home/v2root # Variant 2 tree </pre> I assume $V1 and $V2 both at one time looked like $M, but have each evolved separately, right? <p> And presumably, you have a snapshot of $M somewhere, right? As well as current instantiations of $V1 and $V2? And all of these are on a Unix filesytem somewhere, in the /home partition? <p> The natural way to handle this in Perforce is to create a depot that contains all three variants. E.g., let's call them: <pre> //depot/Master //depot/v1root //depot/v2root </pre> I will describe how you'd set these up and use them in Perforce, but I'm not going to match your acceptance test blow-for-blow, because I didn't completely understand what you were doing. If you'll take a look at what I describe first, I'll be happy to answer any questions you have that will aid in setting up your acceptance test. <p> So first, here's how you load those codelines into Perforce. (I'll explain using the command line interface, not the GUI, because it's easier to demonstrate in email.) <p> First, set up a client view that "maps to the world". (I'm assuming you're going to load your codeline variants from Unix): <pre> cd /home setenv P4CLIENT world-unix p4 client <p> | Client: world-unix | Root: /home | View: | //depot/... //world-unix/... </pre> Now, load the Master codeline: <pre> cd /home/Master find . -type f -print | p4 -x - add p4 submit </pre> Branch the Master codeline into the v1root and v2root codelines: <pre> p4 integ -v //depot/Master/... //depot/v1root/... p4 integ -v //depot/Master/... //depot/v2root/... p4 submit </pre> The 'integ -v' only operates on the depot -- it doesn't affect any local files. <p> Now, submit the actual v1root files as the first set of deltas applied to the //depot/v1root codeline: <pre> cd /home/v1root p4 flush ... #like "sync", but doesn't alter workspace files <p> find . -type f -print | p4 -x - add #the result of this step is #that any files in /home/v1root #not already in //depot/v1root #will be opened for add. <p> p4 diff -se | p4 -x - edit #and this opens for edit any files #which exist but whose contents #have been changed <p> p4 diff -sd | p4 -x - delete #and this opens for delete any #files which are in //depot/v1root #but not in /home/v1root. p4 submit </pre> Now, do the above for v2root as well. <p> You now have 3 codelines in the depot related by integration. Any user can map to one (or more) of the codelines and submit changes to that codeline. E.g., say I wanted to work on NT in //depot/v2root. I'd set up my workspace thus: <pre> p4 set P4CLIENT=laura-ws p4 client <p> | Client: laura-ws | Root: C:\ws | View: | //depot/v2root/... //laura-ws/v2root/... </pre> Now, I can sync my workspace and work on files in the c:\ws\v2root path. I open files with <b>p4 edit</b> make changes to them, and put my changes into the depot with <b>p4 submit</b>. (Or I could use the GUI, of course.) Changes I submit will go in //depot/v2root. <p> You can propagate changes from //depot/v2root into //depot/Master, as long as you are using a client view that is mapped to the //depot/Master codeline. So, the "laura-ws" client wouldn't work, but the "world-unix" one would. Or, you could set up a client just for working on //depot/Master files: <pre> p4 set P4CLIENT=robert-master p4 client <p> | Client: robert-master | Root: F:\ws | View: | //depot/Master/... //robert-master/Master/... </pre> To propagate changes from v2root into Master: <pre> p4 sync #makes sure you have head revs of target files <p> p4 integ //depot/v2root/... //depot/Master/... p4 resolve p4 submit </pre> You can do the same thing to propagate from v1root into Master, also using the 'robert-master' client workspace. (You need simply to be using a client mapped to the <i>target</i> files in an integration): <pre> p4 sync p4 integ //depot/v1root/... //depot/Master/... p4 resolve p4 submit </pre> (The <b>p4 resolve</b> step is where you get to handle conflicts between v1root changes and v2root changes.) <p> Later on down the line, you could branch your patch line. We'll say it's going to be called //depot/patch1. <p> You could use that 'world-unix' client again, because when you're mapped to the world you're mapped to //depot/patch1. Or maybe you'd want to modify your 'robert-master' client spec so you could do the integrations on NT. So you add a mapping for //depot/patch1 to your client view: <pre> p4 client <p> | Client: robert-master | Root: F:\ws | View: | //depot/Master/... //robert-master/Master/... | //depot/patch1/... //robert-master/patch1/... <p> </pre> To create the //depot/patch1 codeline: <pre> p4 integ //depot/Master/... //depot/patch1/... p4 submit </pre> You can pull changes from Master into patch1 as needed: <pre> p4 sync //depot/patch1/... p4 integ //depot/Master/... //depot/patch1/... p4 resolve p4 submit </pre> Perforce keeps track of what's been integrated. If you try to do the above <b>p4 integ</b> a second time, Perforce will tell you all revisions have already been integrated (unless someone has submitted something into //depot/Master in the interim!). <p> If you look in the manual you'll see that there are all kinds of refinements to how you specify which changes are being integrated. For example, to propagate changes up to and including changelist 341 from Master into patch1: <pre> p4 integ //depot/Master/...@341 //depot/patch1/... p4 resolve p4 submit </pre> Or to propagate changelist 435, and only changelist 435, from patch1 back into Master: <pre> p4 integ //depot/patch1/...@435,@435 //depot/Master/... p4 resolve p4 submit </pre> You can also use the codelines paths (also called "filepatterns" or "filespecs" in our documentation) in reporting commands. <p> E.g., to list the files in the patch1 codeline: <pre> p4 files //depot/patch1/... </pre> To show which changelists were submitted directly into the v2root codeline: <pre> p4 changse //depot/v2root/... </pre> To show changelists which were either submitted directly or integrated into the v2root codeline: <pre> p4 changes -i //depot/v2root/... </pre> To show who has files opened in the Master codeline: <pre> p4 opened -a //depot/Master/... </pre> <p> Note that your branching structure is: <pre> Master / | \ / | \ / | \ v1root v2root patch1 </pre> I.e., v1root, v2root, and patch1 are all "children" of Master. That means it is a piece of cake to propagate changes between v1root and Master, but you can't propagate a change directly between v1root and patch1, say, without affecting Master. (Actually, you can, but you'd have to do an integration to reset the base, which effectively rearranges the branching structure.) <p> So when you set up your depot codelines, keep in mind that Perforce makes it easy to propagate changes between parent-child codeline pairs, but propagating changes between further removed codelines pairs is more complicated. <p> Also FYI: If you are doing your <b>p4 resolve</b> commands on Sun, you can set P4MERGE to 'filemerge' and use Sun's nifty graphical merge tool instead of editing Perforce's merge file. And I'm sure there are some equivalent NT tools. <p> Hope this helps. I hope I haven't made too many typos -- I don't always proofread as well as I type.... <p> </blockquote> <p> <p> <i>(August 1998)</i> </p> <font size=-2><b><a href="branching.html#br09">[INDEX]</a></b></font> <p> <hr> <h6>This is file $Id: //guest/universitytexas/faq/br09.html#1 $ in the <a href="http://public.perforce.com/public/index.html">Perforce Public Depot</a></h6> </body> </html>
|#1||684||jim_dowsett||Beginning point for UTA se1 CSE5324 summer 2001 version control/file sharing project.|
Publish "Branching FAQ"
(pull in changes from //guest/laura_wingerd/perforce/faq/... )
|#1||83||laura_wingerd||The Branching Papers.|