When check-in, text files with \n line terminator are modified to use \r\n line terminator ?

[amatei]

Hi,

I use Windows 7 operating system and PTC Integrity 10.6.0.7337, API Version 4.14.7337

I have some text files where the line separator is \n (0A hexa).

I see that after checking in these files and then checking them out, the file size is larger ?!

The difference is given by the line terminator which appears to have been suddenly changed to \r\n (0D 0A hexa)

So why has the PTC Integrity client changed the line terminator of my text files ? I want them stored as they are originally.

Thanks !

[KaelLizak · Accepted solution]

Hello Alexandru Matei‌,

Integrity Lifecycle Manager Source Control and Configuration Management by default uses the line terminators specified by the operating system in text archives.  You can change that to use a specific line termination option, as discussed in case solution CS177152.  There is no option to not change line terminators at all.

It is possible to not modify line terminators at all by changing the archive type from text to binary, but that causes other problems, mainly that disk space use increases dramatically, because the entirety of each revision is stored, instead of storing by reversed diffs, but there might be some other issues as well.

Regards,

Kael

Edited 2016-02-26EST13:53:  Corrected hyperlink to CS177152

[amatei]

Thank you very much for replying. In my case I have chosen to change the archive type from text to binary...

I have some  text master files used in unit testing, which for some reason are ended only with \n (0A hexa).

These master files are text files that I compare against new output from subsequent unit test runs.

So I can't change the line terminator of the master file,  the master file has to  be stored as is in the PTC repository, otherwise some assertEquals will  fail after being  checked-out....

P.S. I get a "Content not found" when click on the CS177152 link...

[KaelLizak]

Hello Alexandru Matei‌,

Ah, yes.  In that case, it sounds like you want to store them as binary archives to lock them.

I'm sorry, that's my fault for munging the hyperlink for CS177152.  I've corrected it in the original post, now.

Regards,
Kael