Setting Perforce line endings

Question

I'm using perforce to manage some code. I have a workspace set up on my local machine and on the unix box. However recently perforce started adding ^M characters to end of the lines which caused issue when running the code in the unix env. How can I set my perforce locally not to do this when editing files. I'm using Notepad++ to edit locally

Answer 1

I'd recommend using Unix line-endings for both clients.

Unix line endings, despite the name, will tell the perforce client not to modify the line-endings when files are synced from how it is submitted originally. With this set on both clients, if you create a file on Windows and sync it to Unix it will still have Windows line-endings but it shouldn't pose a problem on Unix and perforce won't remove/add characters which leads to the ^M.

One small disadvantage is Windows machines will need to Unix line-endings aware utilities such as Notepad++ but that doesn't sound like an issue for you.

In our team environment where Unix, Mac and Windows are all used on the same depot, all our clients are forced to Unix line-endings by a simple one line trigger on the [Unix] server so that nobody suffers this issue (it also forces submitunchanged and rmdir but you may choose to strip these):

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

Answer 2

It sounds like you need to set the LineEnd option to "share" in your client spec.

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

Answer 3

The Perforce documentation tries to dumb down its EOL settings. It fails because EOL problems are always complicated and cannot be dumbed down. Here's the summary of what all the different p4 client settings do "for real". This is learned the hard way by slowly reading the entire Perforce documentation on this topic, some other stackoverflow answers and of course some trial and error (hint: p4 client + p4 diff -f ...)

• unix: no conversion ever because Perforce assumes its internal database is entirely 'LF-normalized' even though this is not strictly enforced! More below.
• win: converts CRLF -> LF on input, LF -> CRLF on output
• local: Default value. Performs win conversions on Windows, performs no (unix) conversion on macOS X, Linux and any other Unix - including Windows Subsystem for Linux.
• share: = "Cleanup CRLF". Converts CRLF to LF on input, no conversion on output.
• mac: pre-macOS X so let's ignore it to keep things slightly simpler

As is often the case, the caveat indirectly describing the key design issue tells more than all the rest of the documentation on this topic:

For example, saving a text file with CRLF line-endings in a unix workspace and then submitting it results in the files being stored in the depot with extra CR characters at the end of each line. When these files are synced to other unix workspaces, they will have CRLF line-endings rather than the correct LF line-endings, and when these files are synced to win workspaces, they will have CRCRLF line-endings (since each LF in the original file is converted to CRLF).

Note earlier statements on the same page give the (wrong!) impression that "everything is LF internally".

While not strictly enforcing LF internally, the Perforce manual warns about some operations possibly struggling when some non-LF end of lines are found internally. Hopefully just spurious but harmless ^M characters showing up when storing CRLF? Good thing lone CRs and pre-macOS X are dead now.

PS: unless it's too late use unix and let editors deal with end of lines; not version control. Editors are almost all pretty good at it and better than version control. No EOL conversion in version control is for instance the only practical way to have some build.sh and some other build.bat files in the same place.