Binding workspaces to the build server

At this point, there should be two servers in operation:

• a master server named master, with a server ID of master-1666
• a build server named build-1667, with a server ID of build-1667

1. Bind client workspaces to the build server.

   Because this server is configured to offer the build-server service, it maintains its own local copy of the list of client workspaces (db.domain and db.view.rp) and their respective have lists (db.have.rp).

   On the build server, create a client workspace with p4 client:

   $ p4 -c build0001 -p build:1667 client build0001

   When creating a new workspace on the build server, you must ensure that your current client workspace has a ServerID that matches the ServerID required by build:1667. Because workspace build0001 does not yet exist, you must manually specify build0001 as the current client workspace with the -c clientname option and simultaneously supply build0001 as the argument to the p4 client command. See the Support Knowledgebase article on "Build Farm Client Management".

   When the p4 client form appears, set the ServerID: field to build-1667. If the ServerID is not set manually, it will be set automatically when the form is saved.

2. Sync the bound workspace.

   Because the client workspace build0001 is bound to build-1667, users on the master server are unaffected. However, users on the build server are able to edit its specification and sync it:

   $ export P4PORT=build:1667
   $ export P4CLIENT=build0001
   $ p4 sync

   The build server’s have list is updated, but does not propagate back to the master.

In a real-world scenario:

• your organization’s build engineers would re-configure your site’s build system to use the new server by resetting their P4PORT to point directly at the build server. Even in an environment in which continuous integration and automated build tools create a client workspace (and sync it) for every change submitted to the master server, performance on the master would be unaffected.
• performance on the master is likely to improve for all users because of the reduction of read and write operations on the master server’s database.