Customizing Perforce Line Ends

Question

I use perforce to manage some code. I have a workspace configured on my local computer and in a unix block. However, perforce recently started adding ^ M characters to the end of lines, which caused a problem when running code on unix env. How can I install my perforce locally so as not to do this while editing files. I am using Notepad ++ for local editing.

Answer 1

I would recommend using Unix lines for both clients.

Unix line endings, despite the name, will tell the perforce client not to change line endings when files are synchronized with the source data. With this set on both clients, if you create a file on Windows and synchronize it with Unix, it will still have linear Windows endings, but it should not be a problem on Unix, and perforce will not remove / add characters, resulting in ^ M.

One of the small drawbacks is that Windows computers will require Unix utilities with string support such as Notepad ++, but this doesn't seem to be a problem.

In our team environment, where Unix, Mac, and Windows are used in the same warehouse, all our clients are forced to restrict the Unix line to a simple single-line trigger on the [Unix] server, so that no one encounters this problem (it also causes submitunchanged and rmdir but you can take them off):

clientspec form-in client "sed -i -es/LineEnd.*/LineEnd:unix/ -es/submitunchanged/revertunchanged/ -es/normdir/rmdir/ %formfile%" 

Answer 2

It looks like you need to set the LineEnd parameter for “sharing” in your client specification.

See: http://www.perforce.com/perforce/doc.current/manuals/cmdref/client.html#1040665

Answer 3

Perforce documentation is trying to find EOL settings. This fails because EOL problems are always complex and cannot be drowned out. Here is a summary of what all p4 client settings do for real. It’s hard to understand, slowly reading all the Perforce documentation on this topic, some https://stackoverflow.com/a/3129/ and, of course, trial and error (hint: p4 client + p4 diff -f... )

• unix : no conversion ever happens because Perforce assumes its internal database is fully “normalized by LF”, although this is not strictly enforced! More details below.
• win : converts CRLF -> LF on input, LF -> CRLF on output
• local : default value. Performs win conversion on Windows, does not ( unix ) conversion on macOS X, Linux, or any other Unix, including the Windows subsystem for Linux.
• share : = "Clearing CRLF". Converts CRLF to LF on input, without conversion on output.
• mac : pre-macOS X, so let's ignore it to make things a little easier

As it often happens, the caution, indirectly describing a key design problem, says more than the rest of the documentation on this topic:

For example, saving a text file with CRLF line endings in the unix workspace and its subsequent transfer leads to saving the files to the storage with additional CR characters at the end of each line. When these files are synchronized with other unix workspaces, they will have CRLF line endings, not the correct LF line endings, and when these files are synchronized with win workspaces, they will have CRCRLF line endings (since each LF in the source file is converted to CRLF )

Note that earlier statements on the same page create (incorrectly!) The impression that “everything is inside the bass”.

While it is not strictly enforcing LF internally, the Perforce manual warns of some operations that may be difficult when some non-LF line ends are inside. Hopefully when you save CRLF, fake, but harmless ^ M characters appear? It's good that lone CRs and pre-macOS X are now dead.

PS: unless it's too late to use unix and let editors figure out the end of lines; not version control. Almost all editors are good at this and better than version control. For example, converting an EOL in a version control system is the only practical way to have multiple build.sh and some other build.bat files in one place.