How do I determine the correct Perforce client (workspace)?

Question

I have a Windows build bat that creates a Perforce commit and label on a successful build.

However, I have not found any way to programmatically determine the correct Perforce client.

Unlike all the other source control systems I'm aware of, p4 and p4v do not create any local config files specifying anything about the remote server.

While it is safe to set the Helix server address globally, and the user can be easily found, the client name is unique to each machine.

All of the methods I know of to specify the client require manual configuration:

1. "p4 set P4CLIENT=%my_client_name%"
2. "p4 -c %my_client_name%"
3. Create a ".p4config" file in every local workspace containing the client name and set P4CONFIG=.p4config

Note: Method (1) is global across all processes, so , and therefore breaks all other p4 commands that might be running on the same build or development machine.

We currently use method (3), however it relies on manually creating the proper .p4config file after setting up the workspace.

The Perforce server knows the local path of the workspace as I can see this in P4V, and p4 raises an error if the local path does not match the client specified in .p4config.

How can my batch file programmatically determine which p4 client matches the local machine, user and path?

Answer 1

A few different things to think about that potentially eliminate this whole problem if you're able to take advantage of them:

• If you never set P4CLIENT in the first place, it defaults to the client host name, which will generally be unique to the client, and will automatically be availble to any p4 command without you having to discover it. (This applies more to p4 users than P4V users, since P4V prompts you to type in a client name, IIRC, rather than simply using the host.)
• Local servers set up with p4 init will automatically set up a P4CONFIG for you in the workspace root.
• If you're using P4V, and you set up your build script as a P4V custom tool, it will automatically set up the environment for you (including P4CLIENT) according to the active connection. (I'm bolding this one because my guess is that P4V users account for most of the difficulty you're having with this tool -- anyone using p4 as their primary client has probably already figured out how to set up their environment in a way that works well with scripts.)

If none of those options are available, you can potentially write a script that tries to guess the right workspace based on available pieces of information:

• The current host (P4HOST) vs the Host: in the client spec
• The current directory (PWD) vs the Root: in the client spec
• The current user (P4USER) vs the Owner: in the client spec

For P4V users, examining the P4V config file is also an option.

Be aware, however, that a user who's gone out of their way to configure things in a confusing way can easily thwart any sort of automation you think of:

• A client spec can have a blank Host:, allowing it to be used from any host (this is generally bad, but you're allowed to do it)
• A client spec can have a Root: of null or / so that the mapping can span multiple drives (best avoided IMO, but occasionally useful)
• Multiple client specs can have the same or overlapping Root:s (a really bad idea IMO, but you're allowed to do it)
• You can use a client spec that's owned by someone else as long as it's not locked (I don't recommend this either, but it certainly happens)

How much you have to worry about users thwarting your efforts to guess their intentions is very site-specific. Ultimately, my recommendation is to focus on making sure that clients are configured correctly, and that your tooling is able to take advantage of that configuration, rather than trying to come up with ways to guess how to fix the configuration within your tooling.