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 ... [gory details elided].
First, my assumptions. You have:
M=/home/Master # The last known good source V1=/home/v1root # Variant 1 tree V2=/home/v2root # Variant 2 treeI assume $V1 and $V2 both at one time looked like $M, but have each evolved separately, right?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?
The natural way to handle this in Perforce is to create a depot that contains all three variants. E.g., let's call them:
//depot/Master //depot/v1root //depot/v2rootI 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.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.)
First, set up a client view that "maps to the world". (I'm assuming you're going to load your codeline variants from Unix):
cd /home setenv P4CLIENT world-unix p4 clientNow, load the Master codeline:| Client: world-unix | Root: /home | View: | //depot/... //world-unix/...
cd /home/Master find . -type f -print | p4 -x - add p4 submitBranch the Master codeline into the v1root and v2root codelines:p4 integ -v //depot/Master/... //depot/v1root/... p4 integ -v //depot/Master/... //depot/v2root/... p4 submitThe 'integ -v' only operates on the depot -- it doesn't affect any local files.Now, submit the actual v1root files as the first set of deltas applied to the //depot/v1root codeline:
cd /home/v1root p4 flush ... #like "sync", but doesn't alter workspace filesNow, do the above for v2root as well.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.
p4 diff -se | p4 -x - edit #and this opens for edit any files #which exist but whose contents #have been changed
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
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:
p4 set P4CLIENT=laura-ws p4 clientNow, I can sync my workspace and work on files in the c:\ws\v2root path. I open files with p4 edit make changes to them, and put my changes into the depot with p4 submit. (Or I could use the GUI, of course.) Changes I submit will go in //depot/v2root.| Client: laura-ws | Root: C:\ws | View: | //depot/v2root/... //laura-ws/v2root/...
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:
p4 set P4CLIENT=robert-master p4 clientTo propagate changes from v2root into Master:| Client: robert-master | Root: F:\ws | View: | //depot/Master/... //robert-master/Master/...
p4 sync #makes sure you have head revs of target filesYou 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 target files in an integration):p4 integ //depot/v2root/... //depot/Master/... p4 resolve p4 submit
p4 sync p4 integ //depot/v1root/... //depot/Master/... p4 resolve p4 submit(The p4 resolve step is where you get to handle conflicts between v1root changes and v2root changes.)Later on down the line, you could branch your patch line. We'll say it's going to be called //depot/patch1.
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:
p4 clientTo create the //depot/patch1 codeline:| Client: robert-master | Root: F:\ws | View: | //depot/Master/... //robert-master/Master/... | //depot/patch1/... //robert-master/patch1/...
p4 integ //depot/Master/... //depot/patch1/... p4 submitYou can pull changes from Master into patch1 as needed:p4 sync //depot/patch1/... p4 integ //depot/Master/... //depot/patch1/... p4 resolve p4 submitPerforce keeps track of what's been integrated. If you try to do the above p4 integ a second time, Perforce will tell you all revisions have already been integrated (unless someone has submitted something into //depot/Master in the interim!).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:
p4 integ //depot/Master/...@341 //depot/patch1/... p4 resolve p4 submitOr to propagate changelist 435, and only changelist 435, from patch1 back into Master:p4 integ //depot/patch1/...@435,@435 //depot/Master/... p4 resolve p4 submitYou can also use the codelines paths (also called "filepatterns" or "filespecs" in our documentation) in reporting commands.E.g., to list the files in the patch1 codeline:
p4 files //depot/patch1/...To show which changelists were submitted directly into the v2root codeline:p4 changse //depot/v2root/...To show changelists which were either submitted directly or integrated into the v2root codeline:p4 changes -i //depot/v2root/...To show who has files opened in the Master codeline:p4 opened -a //depot/Master/...Note that your branching structure is:
Master / | \ / | \ / | \ v1root v2root patch1I.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.)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.
Also FYI: If you are doing your p4 resolve 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.
Hope this helps. I hope I haven't made too many typos -- I don't always proofread as well as I type....
(August 1998)
[INDEX]