End-of-line (newline) characters for files

Development
21

Thus spake viewofheaven:

“uckelman” wrote:

“viewofheaven” wrote:

The file for which I just submitted a suggested patch:
EnumeratedPropertyPrompt.java

I checked this file from trunk@7961 in a hex editor and found no 0x0D
anywhere. Where exacty is the \r you’re seeing?

Every single line! I used XVI32 (hex editor) to check it too, and found
the same thing that my Emacs showed me.

Is anyone else seeing this? Is my TortoiseSVN doing a number on me? My
checkout of trunk shows a good 50% of files with CRLF and the other 50%
with LF. No mixture of CRLF and LF within any single file, though.

I checked again just to be sure. I see no CRs there at all.

“pgeerkens” wrote:

I recently stumbled on some html files in the tree recently that must
have had only LF after downloading

This is a vital clue! On Windows 7 TortoiseSVN, a checkout does not seem
to auto-convert all line endings to anything else. On Windows 7 Cygwin
SVN, there does seem to be an auto-conversion of line endings to LF.
So that could explain why Joel isn’t seeing the CRLF on checkout?

I’m not using Cygwin. I’m not even using Subversion everywhere. I am for
3.1, but for the trunk, I’m using git as a Subversion client. I see no
CRs in either one.

We should put up comprehensive code formatting policies, and HowTo(s)
(for various IDEs) to adhere to such policies. That should make it easy
for every developer to adhere to the code formatting policy.

I intend to do this for V4.

–
J.

22

Nothing against vi - I would still use it in the right circumstance, and have once or twice installed it (and sed) to windows - but I stopped working for companies that coded for UNIX. Also, the functionality gap between vi and other code editors narrowed.

23

Well, how about Windows 7 with TortoiseSVN? Have you checked that? I really am sure there are CRLF in 50% of the files.

If it were all CRLF, I would think there’s been some auto-conversion upon check out. But there are CRLF in just 50% of the files.

Anyway, I’ll just commit my changes using LF for whatever files I’m committing.

Was just trying to give you a heads up regarding possible corruption of line endings in SVN repos.

24

Thus spake viewofheaven:

“uckelman” wrote:

I’m not using Cygwin. I’m not even using Subversion everywhere. I am
for 3.1, but for the trunk, I’m using git as a Subversion client. I
see no CRs in either one.

Well, how about Windows 7 with TortoiseSVN? Have you checked that? I
really am sure there are CRLF in 50% of the files.

I can’t, I don’t have access to Windows 7.

Anyway, I’ll just commit my changes using LF for whatever files I’m
committing.

Was just trying to give you a heads up regarding possible corruption of
line endings in SVN repos.

I appreciate the notice, but this should be ok, really, since every text
editor that anyone codes in can handle it.

–
J.

25

Actually, I was worried about inconsistent character codes (for line endings) in SVN repos. That could throw us some problems later on. At the least, it means a systemic irregularity that should be resolved, much like how “tabs must always be represented by spaces, or vice versa, all the time, choose one or the other”.

Another file that has CRLF: PieceMover.java in package “VASSAL.build.module.map”.

I’ll commit my changes in LF, as per the standard SVN repos practice.

26

I think astyle might be the code formatter we’re looking for.