Perforce Public Knowledge Base - Creating Vendor Branches for Third Parties
Perforce Software logo
Reset Search
 

 

Article

Creating Vendor Branches for Third Parties

« Go Back

Information

 
Problem

Working Disconnected From The Perforce ServerThis article describes a strategy for setting up a "vendor branch" in your depot where you can submit source code modified by an outside source.

Solution

When the third party delivers code (a "vendor drop"), you want to be able to easily identify the changes made and merge them into your codeline, if necessary.

Your branching structure needs to accurately reflect the common ancestry of the local branch and the vendor branch -- so that when you do a merge, Perforce can automatically pick a base that is a common ancestor, and the merge algorithm can do the work of determining which lines to keep and which lines to remove.

When setting up your vendor branch, you should use the most recent revision of your code base that matches the version sent to the third party.

For example, you have a development project stored in your depot under "//depot/main/gui". You outsourced development on this project to Gray Gloves Software, and you sent them all the source under "//depot/main/gui" that was current as of change 2320.

To branch a codeline for third-party use you would use the following command:

p4 integ -v //depot/main/gui/...@2320 //depot/ggs/gui/...   
p4 submit

By default, Perforce copies the target files ("//depot/ggs/gui/...") to their corresponding directories in the client workspace. For faster completion, the -v flag disables this server to client transfer.

To import a vendor code drop, perform the following steps:

  1. Set up a new, empty client workspace that is mapped to the "//depot/ggs/gui/... codeline". Example:
    Client: ggs-drop
    Root:	c:\ggs
    View:
      //depot/ggs/gui/... //ggs-drop/gui/...
    
  2. Extract the vendor files into the empty "ggs-drop" workspace using the example workspace,  "c:\ggs\gui".
     
  3. Use the p4 flush command to make Perforce think the workspace is synced to the head revisions:
    p4 flush //depot/ggs/gui/...
    
  4. Use the technique shown in Working Disconnected From The Perforce Server   and Using Remote Depots to create a changelist of all the files changed by the people at GGS:
  5. cd c:\ggs\gui
    p4 diff -sd ... | p4 -x - delete
    p4 diff -se ... | p4 -x - edit
    dir/s/b/a-d | p4 -x - add
    

    On Unix and Mac OS X, the last line would be:

    find . -type f | p4 -x - add
    

    Note: If there is a P4CONFIG file at the root of the branch this command can be modified to avoid adding the P4CONFIG file:

    find . -type f -not -name $P4CONFIG | p4 -x - add
  6. Submit the changelist.

The vendor file changes are now in the depot. Performing these steps for each code drop ensures that third-party source code is properly versioned, and that the changes are clearly distinguished.

At some point you might want to pull the vendor changes into your codeline. To import vendor changes, integrate from the vendor branch into your codeline. For example:

p4 integ //depot/ggs/gui/... //depot/main/gui/...
p4 resolve
p4 submit

Using Remote Depots

If your vendor also uses Perforce you might be able to access their depot directly as a remote depot. See KB article #30 for more information about using remote depots.
 

Related Links

Feedback

 

Was this article helpful?


   

Feedback

Please tell us how we can make this article more useful.

Characters Remaining: 255