Setting Up Multiple Projects in Perforce

Info & Tags

Article #:
20
Created:
03/06/07
Modified:
10/30/08
Tags:
depot, multiple projects, server

Related Articles

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 under a single Perforce Server
  • Put each project under its own Perforce Server

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 under a single Perforce Server

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 this method as with the first. The same Perforce database is used to store status and history for all projects.

In fact, the only significant difference with this method is that in the Perforce Server's P4ROOT directory each project is in its own subdirectory. This allows you to use symbolic links to put each subdirectory on a separate filesystem if your server is running on Unix. Otherwise, your choice between this method and the first is really just a matter of preference.

Put each project under its own Perforce Server

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.