Perforce Public Knowledge Base - Creating Vendor Branches for Third Parties
Downloads Blog Company Integrations Careers Contact Try Free
Menu Search
Reset Search



Creating Vendor Branches for Third Parties

« Go Back



This article describes a strategy for setting up a "vendor branch" in your depot where you can submit source code modified by an outside source.


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:

For Windows:

cd c:\ggs\gui
p4 diff -sd ... | p4 -x - delete
p4 diff -se ... | p4 -x - edit
dir/s/b/a-d | p4 -x - add

For Unix and MacOS:

cd /ggs/gui
p4 diff -sd ... | p4 -x - delete
p4 diff -se ... | p4 -x - edit
find . -type f | p4 -x - add

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

find . -type f -not -name $P4CONFIG | p4 -x - add
  1. Set up a new, empty client workspace that is mapped to the "//depot/ggs/gui/... codeline". Example:

    Client: ggs-drop
    Root:	c:\ggs
      //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 update the workspace "have" list as if 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. 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. For more information please refer to the Helix Versioning Engine Administrator Guide: Fundamentals chapter, Using remote depots for code drops.

Related Links



Was this article helpful?



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

Characters Remaining: 255