Setting up multiple projects in Perforce

SUMMARY

Recommendations for setting up multiple projects in Perforce.

DETAILS

There are three ways you might approach this:

1. Put each project in a separate directory under a single depot
2. Put each project in a separate depot under a single Perforce Server
3. Put each project under its own Perforce Server

Put each project in a separate directory under a single depot

In this method, all your projects appear under the //depot directory. E.g., say you are developing three separate products, a server, an administrative interface, and browser application. You might set up your projects thus:

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

Client workspaces can be mapped to one or more of these paths to work in 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.

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. If your server is running on Unix, this allows you to use symbolic links to put each subdirectory on a separate filesystem. 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, etc.

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 won't 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'll have to use remote depot support to copy files and merge changes across projects. See Using Remote Depots for more information.
• Users will have to switch P4PORT settings to see change histories, etc. in another project.
• Common tools would have to be replicated in all of the projects (or you'd have to set up yet another project to house your common tools).

If you have any shared development across your projects, we recommend against putting them under separate servers. However, if your projects are completely independent of each other, this method may be appropriate.