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 tree
I 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:

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.

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 client

| Client: world-unix | Root: /home | View: | //depot/... //world-unix/...

Now, load the Master codeline:
        cd /home/Master
        find . -type f -print | p4 -x - add
        p4 submit
Branch the Master codeline into the v1root and v2root codelines:
        p4 integ -v //depot/Master/... //depot/v1root/...
        p4 integ -v //depot/Master/... //depot/v2root/...
        p4 submit
The '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 files

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

Now, do the above for v2root as well.

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 client

| Client: laura-ws | Root: C:\ws | View: | //depot/v2root/... //laura-ws/v2root/...

Now, 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.

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 client

| Client: robert-master | Root: F:\ws | View: | //depot/Master/... //robert-master/Master/...

To propagate changes from v2root into Master:
        p4 sync  #makes sure you have head revs of target files

p4 integ //depot/v2root/... //depot/Master/... p4 resolve p4 submit

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 target files in an integration):
        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 client

| Client: robert-master | Root: F:\ws | View: | //depot/Master/... //robert-master/Master/... | //depot/patch1/... //robert-master/patch1/...

To create the //depot/patch1 codeline:
        p4 integ //depot/Master/... //depot/patch1/...
        p4 submit
You can pull changes from Master into patch1 as needed:
        p4 sync //depot/patch1/...
        p4 integ //depot/Master/... //depot/patch1/...
        p4 resolve
        p4 submit
Perforce 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 submit
Or to propagate changelist 435, and only changelist 435, from patch1 back into Master:
        p4 integ //depot/patch1/...@435,@435 //depot/Master/...
        p4 resolve
        p4 submit
You 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:

                       /  |  \
                      /   |   \
                     /    |    \
                v1root  v2root  patch1
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.)

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)


This is file $Id: //guest/michael_roach/perforce/faq/br09.html#1 $ in the Perforce Public Depot