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



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.


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
      //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. More information about using remote depots.

Related Links



Was this article helpful?



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

Characters Remaining: 255