We here at the SHA webteam use Perforce for our version control system. It’s nice in many ways, but it can be a little unwieldy at times. Recently, I wanted to use a second computer at work, but wanted to use the same workspace I’ve been using for the past year. My workspace is stored on a networked drive, which is linked to a development server and so forth.

By default a Perforce workspace is tied to one “host” and one “root”. The host is the hostname of your computer on the network, and the root is the location in the file system where the workspace resides. If you try to access the workspace via another computer, Perforce will prevent you from doing so, declaring that the workspace is inaccessible from any computer that’s not the default host.

Luckily, we can change this. In your client spec in perforce, we need to do two things:

• Remove the host name from the host section
• Add an additional file system path to the “AltRoots” section

Removing the original hostname for your workspace effectively removes that requirement from Perforce, and adding the additional file system path tells it how to access the workspace from your other computer.

So say I have a default setup on a PC, and the clientspec contains:

host: SHA-casey
root: J:\perforce\depots\cjd47

In order to make this work with a Mac, I need to know the location of the depot in the Mac’s filesystem. If we’re mounting a SAMBA drive or something, it should be located in the /Volumes directory like so:

/Volumes/FILESTORE/perforce/depots/cjd47

So my modifed clientspec would look something like:

host: 
root: J:\perforce\depots\cjd47
AltRoots: /Volumes/FILESTORE/perforce/depots/cjd47

Everything else in the client spec on the new computer should be the same as the original client name, workspace name, views, etc. When you connect with Perforce, everything should work just fine.