如何确定正确的 Perforce 客户端（工作区）？
我有一个 Windows 构建 bat，它可以在成功构建时创建 Perforce 提交和标签。
但是，我还没有找到任何方法来以编程方式确定正确的 Perforce 客户端。
与我所知道的所有其他源代码控制系统不同，p4 和 p4v 不会创建任何指定有关远程服务器的任何本地配置文件。
虽然全局设置 Helix 服务器地址是安全的，并且可以轻松找到用户，但客户端名称对于每台计算机都是唯一的。
我知道的所有指定客户端的方法都需要手动配置：
- "p4 set P4CLIENT=%my_client_name%"
- "p4 -c %my_client_name%"
- 在每个本地工作区中创建一个“.p4config”文件包含客户端名称并设置 P4CONFIG=.p4config
注意：方法 (1) 在所有进程中是全局的，因此 ，因此会破坏可能在同一构建或开发中运行的所有其他 p4 命令 机器。
我们当前使用方法 (3)，但它依赖于在设置工作区后手动创建正确的 .p4config 文件。
Perforce 服务器知道工作区的本地路径，正如我在 P4V 中看到的那样，如果本地路径与 .p4config 中指定的客户端不匹配，p4 会引发错误。
我的批处理文件如何以编程方式确定哪个 p4 客户端与本地计算机、用户和路径匹配？
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:
- "p4 set P4CLIENT=%my_client_name%"
- "p4 -c %my_client_name%"
- 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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
需要考虑一些不同的事情，如果您能够利用它们，则可能会消除整个问题：
P4CLIENT，它默认为客户端主机名，即通常对于客户端来说是唯一的，并且将自动可用于任何p4命令，而无需您发现它。 （与 P4V 用户相比，这更适用于p4用户，因为 P4V 会提示您输入客户端名称 IIRC，而不是简单地使用主机。）p4 init< 设置本地服务器/code> 将自动在工作区根目录中为您设置一个P4CONFIG。P4CLIENT）。< /strong> （我将这一点加粗是因为我的猜测是 P4V 用户造成了使用此工具时遇到的大部分困难 - 任何使用p4作为其主要客户端的人可能已经意识到了解如何设置他们的环境一种与脚本配合良好的方式。）如果这些选项都不可用，您可以编写一个脚本，尝试根据可用信息猜测正确的工作区：
P4HOST)与客户端规范中的Host:PWD) 与客户端规范中的Root:P4USER）与客户端规范中的Owner:对于 P4V 用户，检查 P4V 配置文件也是一种选择。
但请注意，不遗余力以令人困惑的方式配置事物的用户很容易阻碍您想到的任何类型的自动化：
Host:，从而允许它可以从任何主机使用（这通常是不好的，但您可以这样做）Root:为null或/以便映射可以跨越多个驱动器（最好避免IMO，但偶尔有用）Root：（IMO，这是一个非常糟糕的主意，但您可以这样做）锁定（我也不推荐这样做，但它肯定会发生）您需要担心用户阻止您猜测他们的意图的努力是非常特定于站点的。最终，我的建议是专注于确保客户端配置正确，并且您的工具能够利用该配置，而不是试图想出方法来猜测如何修复工具中的配置。
A few different things to think about that potentially eliminate this whole problem if you're able to take advantage of them:
P4CLIENTin the first place, it defaults to the client host name, which will generally be unique to the client, and will automatically be availble to anyp4command without you having to discover it. (This applies more top4users than P4V users, since P4V prompts you to type in a client name, IIRC, rather than simply using the host.)p4 initwill automatically set up aP4CONFIGfor you in the workspace root.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 usingp4as 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:
P4HOST) vs theHost:in the client specPWD) vs theRoot:in the client specP4USER) vs theOwner:in the client specFor 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:
Host:, allowing it to be used from any host (this is generally bad, but you're allowed to do it)Root:ofnullor/so that the mapping can span multiple drives (best avoided IMO, but occasionally useful)Root:s (a really bad idea IMO, but you're allowed to do it)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.