我正在使用perforce来管理一些代码。我在本地计算机和unix框上设置了工作区。然而，最近perforce开始在行结束时添加^ M个字符，这导致在unix环境中运行代码时出现问题。如何在本地设置perforce，以便在编辑文件时不执行此操作。我正在使用Notepad ++进行本地编辑
答案 0 :(得分：6)
我建议为两个客户端使用Unix line-endings。
Unix行结尾，尽管有名称，但会告诉perforce客户端不在文件与最初提交方式同步时修改行结尾。在两个客户端上设置此设置，如果您在Windows上创建文件并将其同步到Unix，它仍将具有Windows行结尾，但它不应该在Unix上出现问题，perforce将不会删除/添加导致^ M。
一个小缺点是Windows机器需要Unix线路终端感知实用程序，如Notepad ++，但这听起来不像是一个问题。
在我们的团队环境中，Unix，Mac和Windows都在同一个软件仓库上使用，我们所有的客户端都被强制通过[Unix]服务器上的简单一行触发器进行Unix线路终结，这样就没有人会遇到这个问题（它也强制submitunchanged和rmdir，但你可以选择剥离这些）：
clientspec form-in client "sed -i -e s/LineEnd.*/LineEnd:unix/ -e s/submitunchanged/revertunchanged/ -e s/normdir/rmdir/ %formfile%"
答案 1 :(得分：4)
听起来您需要在客户端规范中将LineEnd选项设置为“share”。
请参阅：http://www.perforce.com/perforce/doc.current/manuals/cmdref/client.html#1040665
答案 2 :(得分：1)
Perforce文档试图简化其EOL设置。它之所以失败，是因为EOL问题总是很复杂，并且不能被忽略。这是所有不同的p4 client设置“真实”执行的摘要。通过慢慢阅读有关此主题的 entire Perforce文档，一些other stackoverflow answers，当然还有一些反复试验，很难理解这一点（提示：p4 client + {{1} }）
p4 diff -f ...：因为Perforce假定其内部数据库是完全“ LF规范化的” ，所以从未进行过转换，即使没有严格执行！下面有更多内容。unix：在输入时转换CRLF-> LF，在输出时转换LF-> CRLF win：默认值。在Windows上执行local转换，在macOS X，Linux和任何其他Unix上（包括Windows Linux子系统）不执行（win）转换。unix：=“清理CRLF”。在输入时将CRLF转换为LF，在输出时不进行转换。share：macOS X之前的版本，因此我们将其忽略以使事情更简单通常情况下，the caveat间接描述关键设计问题比该主题的所有其他文档更有意义：
例如，将具有CRLF行尾的文本文件保存在
mac工作区中，然后提交该文本文件，将导致文件存储在软件仓库中，每行末尾带有多余的CR字符。当这些文件同步到其他unix工作区时，它们将具有CRLF行尾而不是正确的LF行尾，并且当这些文件同步到unix工作区时，它们将具有CRCRLF行尾。结尾（因为原始文件中的每个LF都转换为CRLF）。
请注意，同一页面上的早期声明给人（错误！）印象是“所有内容在内部都是LF”。
虽然内部没有严格执行LF，但是Perforce手册警告说，当内部发现某些非LF行尾时，某些操作可能会遇到困难。希望在存储CRLF时仅显示spurious but harmless ^M characters吗？ 好东西，孤岛CR和pre-macOS X现在已经死了。
PS：除非为时已晚，请使用win并让编辑者处理行尾； not 版本控制。编辑器几乎都擅长于此，并且比版本控制要好。例如，在版本控制中没有EOL转换是将某些build.sh和其他build.bat文件放在同一位置的唯一实用方法。