![]() ![]() Where any means a configurable defined on the commit server that is used by all connected servers unless specifically overridden in that particular server's configuration. Headquarters-commit: P4LOG = /home/perforce/servers/commit-hq/log Paris-edge: P4LOG = /home/perforce/servers/edge1/log To display the configuration across all servers, use Viewing the values of configuration variables on all servers Because p4d has precedence over p4 configure, the output of p4 configure show indicates that monitor is set to 2. To indicate that p4d -v set monitor to 2, and p4 configure set monitor to 10. To find out whether a specific configurable variable has been set in more than one way, specify that configurable variable: State of the current server, a named server, or any configurable, including a Helix Core environment variable, useĬonfigurable is displayed along with its value, where the entry in the parentheses ( ) indicates how the value was set: If the output line is. Viewing the values of configuration variables on one server For example, 10M is the default value for the dm.shelve.maxfiles configurable. 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.You can use K and M to represent large numbers. How much you have to worry about users thwarting your efforts to guess their intentions is very site-specific. 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).Multiple client specs can have the same or overlapping Root:s (a really bad idea IMO, 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).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).The current user ( P4USER) vs the Owner: in the client specįor P4V users, examining the P4V config file is also an option.īe 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:.The current directory ( PWD) vs the Root: in the client spec.The current host ( P4HOST) vs the Host: in the client spec.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: ![]() (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 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.Local servers set up with p4 init will automatically set up a P4CONFIG for you in the workspace root.(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.) 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.How can my batch file programmatically determine which p4 client matches the local machine, user and path?Ī few different things to think about that potentially eliminate this whole problem if you're able to take advantage of them: 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 file after setting up the workspace. We currently use method (3), however it relies on manually creating the proper. 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. Create a ".p4config" file in every local workspace containing the client name and set P4CONFIG=.p4config.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.Īll of the methods I know of to specify the client require manual configuration: 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. However, I have not found any way to programmatically determine the correct Perforce client. I have a Windows build bat that creates a Perforce commit and label on a successful build.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |