Home/ Questions/Q 8698609
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-13T01:45:58+00:00

First, let me explain what I am doing. I have a CVS repository that

  • 0

First, let me explain what I am doing. I have a CVS repository that I store 5,000 Data Definition Language files in. These 5,000 files are generated from an external data modeling application, they are text and have windows CRLFs. During development, if I need to make a change, I re-generate the 5,000 files and then overwrite the contents of my local CVS workspace in eclipse. The full overwrite/replacement is to make sure that I don’t miss any updates to files. After overwriting/replacing the files, I use eclipse to do a team < synchronize with repository. When I do this, the comparison flags every single file as an outgoing change because it looks to not be ignoring CRLFs in its comparison. I have “Ignore white space” checked off and the eclipse documentation states that it should be ignoring CRLFs:

 Ignore whitespace option:
 Causes the comparison to ignore differences which are whitespace characters 
 (spaces, tabs, etc.). Also causes differences in line terminators ( LF 
 versus CRLF) to be ignored.

When I open the files in text compare, it shows no diffs but there is an extra CRLF at top of one of the files. Is this a bug or is there an option I am missing in eclipse? It looks like the problem is that it doesn’t ignore CRLFs that are on their own line.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The Eclipse compare dialog doesn’t have a bug; you’re just confused because you’re seeing the output of several, independent problems.

    1. The option “ignore whitespace” only reduces the amount of changes that the compare dialog shows; it has no effect whatsoever on the differences that CVS sees. So as long as the files have the wrong line ending, CVS will complain.

      Some version control systems allow you to specify converters to solve this issue, CVS doesn’t. So you really need to generate files with the correct line endings.

    2. The “single file with extra CRLF” really has a an extra CRLF. Find out why and fix that to make the difference go away.

    3. When generating files, you should never use PrintStream or PrintWriter. It is tempting but these two have many bugs (like close() doesn’t flush(), violating their API contract) plus they use platform dependent line endings which is almost never what you want. Yes, it might work by accident but trust me on this, that’s not what you want. You don’t want you pay check filed on accident, either, right?

      If you don’t use PrintStream nor PrintWriter, then avoid the System property line.separator for the same reasons.

      I suggest to wrote a helper class which has many of the methods of PrintStream / PrintWriter but none of the bugs. Plus it should allow you to set the line delimiter to whatever you need.

    Note: If you use a Writer, make sure you also specify the charset / encoding or the “UTF-8 to bytes” conversion will be as random as the line endings.

    • 0