A New Line on Newlines
A New Line on Newlines
Does anybody object to making the default line ending for source code the unix line ending, \n?
Please voice your support as well.
Please voice your support as well.
-
- Posts: 377
- Joined: Fri Oct 28, 2005 10:28 am
- Contact:
-
- Posts: 377
- Joined: Fri Oct 28, 2005 10:28 am
- Contact:
Our project is being worked on in Lunux and Windows. I only work in Windows and use TortoiseSVN. And there is no action required by me to activiate it
In general line ending handling is done in SVN using properties. There is the prop svn:eol-style which can be set to native to have the files in their native encodings on each platform. See http://svnbook.red-bean.com/en/1.1/ch07 ... sect-2.3.5
You can setup general rules (autoprops) per file type. See http://svnbook.red-bean.com/en/1.1/ch07 ... sect-1.3.2
This can for instance look like this (Taken from the sample config in TortoiseSVN):
In general line ending handling is done in SVN using properties. There is the prop svn:eol-style which can be set to native to have the files in their native encodings on each platform. See http://svnbook.red-bean.com/en/1.1/ch07 ... sect-2.3.5
You can setup general rules (autoprops) per file type. See http://svnbook.red-bean.com/en/1.1/ch07 ... sect-1.3.2
This can for instance look like this (Taken from the sample config in TortoiseSVN):
Code: Select all
[auto-props]
*.c = svn:eol-style=native
*.cpp = svn:eol-style=native
*.h = svn:eol-style=native
*.dsp = svn:eol-style=CRLF
*.dsw = svn:eol-style=CRLF
*.sh = svn:eol-style=native;svn:executable
*.txt = svn:eol-style=native
*.png = svn:mime-type=image/png
*.jpg = svn:mime-type=image/jpeg
No offense
-
- Posts: 377
- Joined: Fri Oct 28, 2005 10:28 am
- Contact:
-
- Posts: 377
- Joined: Fri Oct 28, 2005 10:28 am
- Contact:
Well, I imagine SVN tries to maintain the encoding as it is submitted.
The files I have dealt with are CRLF. I figure SVN stores the files as normalized LF, but has flags to convert them to their original forms, which in my case has been CRLF.
Sometimes my editor gives me troubles; even though I have it set to maintain the same encoding, it seems to convert automatically to another format. Consequently, svn diff screws up. I can fix this by making sure to set explicitly the encoding before saving each time.
I can cope with this, however, I would really like to change it to LF for conceptual reasons. I think the Windows format is stupid.
The files I have dealt with are CRLF. I figure SVN stores the files as normalized LF, but has flags to convert them to their original forms, which in my case has been CRLF.
Sometimes my editor gives me troubles; even though I have it set to maintain the same encoding, it seems to convert automatically to another format. Consequently, svn diff screws up. I can fix this by making sure to set explicitly the encoding before saving each time.
I can cope with this, however, I would really like to change it to LF for conceptual reasons. I think the Windows format is stupid.
-
- Posts: 377
- Joined: Fri Oct 28, 2005 10:28 am
- Contact:
These are different issues probably. Problems can occur when linux users check in CRLF style files, because they are considered to be already LF style and when checked out converted to windows style LF -> CRLF and thus it is made to CRCRLF leaving a CR at the end of each line.
If such files or parts of those are in the repository, this has to be fixed by the team. A workable way were to execute a simple sed script or something s/\r//g to all source files. My bet is, that not all are normalised in terms of line endings in the repository.
Native line endings work just fine with svn, there is nothing to gain, if even windows users had to checkout in lf-style. Not all programs support this as hybrid pointed out, but it is likewise in linux, not all programs like crlf there either (all those ^M at line endings in some editors)
If such files or parts of those are in the repository, this has to be fixed by the team. A workable way were to execute a simple sed script or something s/\r//g to all source files. My bet is, that not all are normalised in terms of line endings in the repository.
Native line endings work just fine with svn, there is nothing to gain, if even windows users had to checkout in lf-style. Not all programs support this as hybrid pointed out, but it is likewise in linux, not all programs like crlf there either (all those ^M at line endings in some editors)
No offense