Setting Up Multiple Projects in Perforce

SUMMARY

There are three ways you can approach setting up multiple projects in Perforce:

• Put each project in a separate directory under a single depot
• Put each project in a separate depot (multiple depots)
  
• Put each project on its own Perforce Server (multiple servers)
  

DETAILS

Put each project in a separate directory under a single depot

In this method all your projects appear under the //depot directory. For example, if you are developing three separate products -- a server, an administrative interface, and a browser application -- you can set up your projects like the following:

//depot/server/...
//depot/admin/...
//depot/browser/...

Client workspaces can be mapped to one or more of these paths to work on these projects. Workspaces can be dedicated to particular projects, and users can set up separate workspaces for each project, or work on all projects in the same client workspace. The Perforce superuser can set permissions on each project to limit user access. Any Perforce superuser has access to, and control over, all projects.

For more information on adding a new directory tree to your Depot, please see KB Article #12, Adding a Directory Tree.

Put each project in a separate depot (multiple depots)

In this method, you create a separate depot for each project. Your project paths would look like:

//server/...
//admin/...
//browser/...

Client workspaces and permissions work exactly the same with the multiple depot configuration as with the single depot configuration. The same Perforce database is used to store status and history for all projects.

The most significant difference with the multiple depot configuration is that, in the Perforce Server P4ROOT directory, each project is stored in its own top-level depot directory (rather than as a subdirectory of a single depot). The multiple depot configuration allows you to use the depot "Map" field to put each top-level depot directory on a separate filesystem, if desired. More on using the Map field can be found in the Command Reference entry for the p4 depot command.

Performance is another consideration in configuring single vs. multiple depots. By splitting projects into separate depots, file paths for many Perforce operations are inherently limited to a more narrow range of files, resulting in reduced need to scan certain database tables. The performance difference is dependent on the particular data sets and usage. For many small installations, there is no appreciable difference. However, for larger installations and for some usage environments, the performance difference might be significant.

Otherwise, your choice between storing projects as subdirectories in a single depot or using multiple top-level depots to store them is primarily a matter of preference.

Put each project under its own Perforce Server (multiple servers)

In this method, if you had three separate projects, you set up three separate Perforce Server installations, each with its own server, its own P4ROOT directory, its own database, and so on.

Advantages:

• Each project is entirely under the control of its own superuser(s).
• The server for each project can be installed on the LAN closest to its users.
• High volume of use on one project does not affect any of the others.

Disadvantages:

• Users can only work in one project at a time.
• Each project would need its own Perforce administrator.
• You have to use remote depot support to copy files and merge changes across projects. See Using Remote Depots for more information.
• Users have to switch P4PORT settings to see change histories and other data from another project.
• Common tools would have to be replicated in all of the projects (or you would have to set up another project to house your common tools).

If you have any shared development across your projects, it is recommended that you not put them under separate servers. However, if your projects are completely independent of each other, a multiple server method might be appropriate.