15

Is there a way to tell Perforce to leave text files alone without setting the file-type as binary? Or barring that, is there a way to tell the Perforce client to diff binaries? Binary usually isn't desirable, because I lose the ability to diff.

To clarify: If I edit and make changes to a *.txt file on my window client, newlines will have CR+LF as per the DOS format. But if I P4 sync on a Unix client, it will have LF only. I need Perforce to keep the format as-is, regardless of where the Perforce client lives.

That said, I do have a work-around: Set file-type as binary; and/or create a branch with text files set as "text", and integrate periodically back into the mainline where text files are set as "binary". But this is an overly-complicated work-around for what should be a very simple problem.

Finally, I'm on Perforce Windows client 2006.2.

Thanks in advance.

Vovanium
  • 3,798
  • 17
  • 23
hythlodayr
  • 2,377
  • 15
  • 23
  • 1
    Here's an IMHO more important use case for the same question: how to store a `build.sh` *and* a `build.bat` in the same directory without breaking either? With network filesystems/VMs/WSL these could even be actively used at the same time. Version control systems should treat user input as "sacred by default". – MarcH Nov 26 '18 at 21:05

5 Answers5

11

Set all of your client/workspace specs to 'unix' line-endings. Then no conversion will take place when you check in on Windows.

See http://answers.perforce.com/articles/KB_Article/CR-LF-Issues-and-Text-Line-endings/

Douglas Leeder
  • 52,368
  • 9
  • 94
  • 137
  • Ok. This is much better. While not ideal, it's far better than having to create a separate branch. Thanks! – hythlodayr Feb 01 '10 at 15:09
  • Link updated to: http://answers.perforce.com/articles/KB_Article/CR-LF-Issues-and-Text-Line-endings/ – Lester Cheung May 01 '13 at 04:31
  • I tried to summarize the (confusing) documentation, please help review: https://stackoverflow.com/questions/10721294/setting-perforce-line-endings/53491975 – MarcH Nov 27 '18 at 02:42
  • Thank you thank you thank you! _Note:_ After I selected unix line ending option in Perforce options, I did a "Get Revision" and selected force to re-get the files, and they still were **not** how I wanted them. However, I converted them once again so that they all had their correct line endings, then I submitted to Perforce 1 more time, and now it is finally working correctly. – Loduwijk Oct 18 '19 at 18:24
5

The Perforce client can handle line ending properly when syncing to different platforms provided you have LineEnd option set properly on your client. Perhaps you have yours set wrong? Open up your client specs and set the LineEnd option according to your needs.

Check out this KB article on their website for more info. Here's an excerpt:

On the server side, Perforce processes all text files using Unix-style LF line-endings. Although Perforce stores server archive files on disk in the operating system's native line termination convention (CR/LF on Windows, LF on Unix), all line-endings are normalized to Unix-style LF line-endings for internal Perforce Server operations such as p4 sync, p4 submit and p4 diff.

On the client workspace side, Perforce handling of line-endings is determined by a global option for each clientspec. When you sync text files to a client workspace with p4 sync, or submit them back to a Perforce Server with p4 submit, their line-endings are converted as specified in the clientspec LineEnd section.

raven
  • 18,004
  • 16
  • 81
  • 112
  • 1
    I was afraid of that, but thank you for the article. Simply put, our Unix perforce clients (and file server) must be able to hold a mix of Windows and Unix text files. Even worse: We have certain localization text files (akin to Java properties files) which the Perforce server mangles. Alas, the only solution there is to set things to binary. – hythlodayr Jan 28 '10 at 21:19
  • @hythlodayr: Do you currently have a support contract with Perforce? If so, you could give them a call. Perhaps they know some tricks that can get it to behave the way you want. – raven Jan 28 '10 at 21:34
  • 1
    The trouble is that it doesn't work and Perforce refuse to acknowledge the bug. Perforce corrupts all text files by default if you ever submit a file from *nix that has Windows line endings or vice-versa. – Richard1403832 Oct 03 '17 at 09:32
  • _... all line-endings are normalized to Unix-style LF..._ is confusing and contradicted by these two other statements on the same page: _On UNIX and Mac OS X client workspaces, the default local setting does not cause any line-end conversion_, and: _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...._ – MarcH Nov 27 '18 at 01:41
3

When adding text files that you want to be considered binary to Perforce, use the command p4 add with the -t option to override the type mapping table. See the documentation here. The example given there is p4 add -t binary file.pdf.

Permaquid
  • 1,950
  • 1
  • 14
  • 15
3

I have just come across exactly the same problem, but have a better solution that does not involve changing client specs (which are international, and not all of which I have write access to).

All of our clients are Windows PCs, but Cygwin is included within the Perforce Depot. Cygwin is a Windows implementation of Unix, and requires that text files use LF for line endings.

A possible solution for older versions of Cygwin is to mount the root using the "text" option, meaning that files can have CR+LF line endings. However, on upgrading to Cygwin 1.7.9, this no longer worked, as mounts are transient unless they are written into /etc/fstab. I did not manage to make this work.

Luckily, the Perforce Guru sitting next to me came up with the solution of changing the filetype to binary+D, which uses the same RCS incremental patch storage as text files, but without the automatic line ending conversion.

I can diff these "text" files successfully between my local workspace and the depot.

Dave Knight
  • 402
  • 3
  • 12
-5

Give the files a different extension.

Permaquid
  • 1,950
  • 1
  • 14
  • 15
  • 1
    Nope, as these are supposed to be production-quality files. One should be able to sync and copy into the environment seamlessly and hassle-free. In the same vein, unix2dos isn't an option either. – hythlodayr Jan 28 '10 at 19:09