7

我正在使用 perforce 来管理一些代码。我在本地机器和 unix 机器上设置了一个工作区。但是最近 perforce 开始在行尾添加 ^M 字符，这在 unix env 中运行代码时会导致问题。如何在编辑文件时在本地设置我的 perforce 不这样做。我正在使用 Notepad++ 进行本地编辑

4

3 回答 3

7

我建议对两个客户端都使用 Unix 行尾。

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%"
于 2012-11-29T22:37:40.137 回答
5

听起来您需要在客户端规范中将 LineEnd 选项设置为“共享”。

请参阅：http ://www.perforce.com/perforce/doc.current/manuals/cmdref/client.html#1040665

于 2012-05-23T18:21:21.680 回答
4

Perforce 文档试图简化其 EOL 设置。它失败了，因为 EOL 问题总是很复杂，不能简单化。p4 client以下是所有不同设置“真正”所做的总结。这是通过慢慢阅读有关该主题的整个Perforce 文档、其他一些 stackoverflow 答案，当然还有一些试验和错误（提示：p4 client+ p4 diff -f ...）来学习的。

  • unix: 从来没有转换，因为 Perforce 假设它的内部数据库是完全“LF-normalized”的，即使这不是严格执行的！更多内容如下。
  • win: 在输入上转换 CRLF -> LF，在输出上转换 LF -> CRLF
  • local： 默认值。win在 Windows 上执行转换，在 macOS X、Linux 和任何其他 Unix（包括 Linux 的 Windows 子系统）上不执行 ( )unix转换。
  • share: = "清理 CRLF"。输入时将 CRLF 转换为 LF，输出时不转换。
  • mac: pre-macOS X 所以让我们忽略它以使事情稍微简单一点

通常情况下，间接描述关键设计问题的警告比有关该主题的所有其余文档都更能说明问题：

例如，将带有 CRLF 行尾的文本文件保存在unix工作区中，然后提交它会导致文件存储在库中，并且每行末尾都有额外的 CR 字符。当这些文件同步到其他unix工作空间时，它们将具有 CRLF 行结尾而不是正确的 LF 行结尾，并且当这些文件同步到win工作空间时，它们将具有 CRCRLF 行结尾（因为原始文件中的每个 LF 都是转换为 CRLF）。

请注意同一页面上的早期陈述给人的（错误的！）印象是“一切都是 LF 内部”。

虽然没有在内部严格执行 LF，但 Perforce 手册警告说，当内部发现一些非 LF 行尾时，某些操作可能会遇到困难。希望在存储 CRLF 时出现虚假但无害的 ^M 字符？幸好单独的 CR 和 pre-macOS X 现在已经死了。

PS：除非来不及使用unix，让编辑处理行尾；不是版本控制。编辑器几乎都非常擅长，并且比版本控制更好。例如，版本控制中没有 EOL 转换是在同一个地方拥有一些build.sh和一些其他文件的唯一实用方法。build.bat

于 2018-11-27T02:41:04.547 回答