Stupid win32 perforce tricks

NickTriantosnick at NickTriantosnick at
Fri Apr 3 09:01:02 PST 1998

You can also set your client root to "null" (no quotes), then make your
client mappings look like:

//depot/mypath/to/myfiles/... //myclient/c:/src/myfiles/...
//depot/secondpath/to/otherstuff/... //myclient/e:/otherstuff/...

I found this in the 97.3 release notes.

- -Nick

At 11:03 PM 4/2/98 -0800, you wrote:
>If you want to create a client that is capable of mapping
>files to different FAT or NTFS drives, just export the 
>drives of interest, and use the UNCs in your perforce client.
>For example suppose I want to map a bunch of perl modules
>to d:/perl/lib/, gnumake and some other scripts to c:/local/bin,
>and a bunch of source to e:/.  Using the win32 explorer,
>I share c:/local as //thelonious/local, d:/perl as 
>//thelonious/perl, and e: as //thelonious/home.  Now I can map 
>gnumake and other script to c:/local/bin, various perl modules
>to d:/perl/lib/.../*.pm, and my current project to e:/project using
>the client below:

>As a side note.  I find it simpler to make a separate client for utilities
>and third party stuff than to include it in every project client.  For
>both thirdparty and in-house utilities the client mappings tend to be
>non-trivial.  For my home machine I want only the bare minimum I need 
>to pull over a modem and when architecture matters I need win32.  For
>my work machine I mostly want a full copy of things and typically need
>solaris versions of binaries.  I find it preferable to get the mappings
>right once and be done with it, since these clients change rarely.
>For builds, I create labels that are rooted at //depot, so I can add
>all the files from all the clients involved in a build, including the
>third-party/in-house-utilities client.
>marc at
- ----
Nick Triantos
Nvidia Corporation         phone: 408/617-4054
1226 Tiros Way             email: mailto:nick at
Sunnyvale, CA 94086          www:

PGP key at:

More information about the perforce-user mailing list