Helix Core is now P4. Product user interfaces will be updated soon. Learn more >>

P4 Server Administration Documentation | 2025.2

# Bind workspaces to the build server

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

- A target server The immediately upstream server for replica servers, edge servers, standby servers, proxies and brokers. See also 'upstream server' and 'central server'. named `london`, with a server ID of london-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 Perforce Knowledge Basearticle 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 target 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 target server.

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 target server, performance on the target server would be unaffected.
- Performance on the target server is likely to improve for all users because of the reduction of read and write operations on the target server's database.

## If not all database tables are needed

If there are database tables that you know your build server does not require, consider using the `-T` filter option to p4 pull. Also consider specifying the `ArchiveDataFilter`, `RevisionDataFilter` and `ClientDataFilter` fields of the build server’s `p4 server` spec form.

Your search for returned results