Unless otherwise noted using a versioned file’s svn:mime-type
property, Subversion assumes the
file contains human-readable data. Generally speaking, Subversion uses
this knowledge only to determine whether contextual difference reports
for that file are possible. Otherwise, to Subversion, bytes are
bytes.
This means that, by default, Subversion doesn’t pay any attention
to the type of end-of-line (EOL) markers used in
your files. Unfortunately, different operating systems have different
conventions about which character sequences represent the end of a line
of text in a file. For example, the usual line-ending token used by
software on the Windows platform is a pair of ASCII control characters—a
carriage return (CR
) followed by a line feed (LF
). Unix
software, however, just uses the LF
character to denote the end of a line.
Not all of the various tools on these operating systems understand
files that contain line endings in a format that differs from
the native line-ending style of the
operating system on which they are running. So, typically, Unix programs
treat the CR
character present in
Windows files as a regular character (usually rendered as ^M
), and Windows programs combine all of the
lines of a Unix file into one giant line because no carriage return–line
feed (or CRLF
) character combination
was found to denote the ends of the lines.
This sensitivity to foreign EOL markers can be frustrating for folks who share a file across different operating systems. For example, consider a source code file with developers who edit this file on both Windows and Unix systems. If all the developers always use tools that preserve the line-ending style of the file, no problems occur.
But in practice, many common tools either fail to properly read a file with foreign EOL markers, or convert the file’s line endings to the native style when the file is saved. If the former is true for a developer, he has to use an external conversion utility (such as dos2unix or its companion, unix2dos) to prepare the file for editing. The latter case requires no extra preparation. But both cases result in a file that differs from the original quite literally on every line! Prior to committing his changes, the user has two choices. Either he can use a conversion utility to restore the modified file to the same line-ending style that it was in before his edits were made, or he can simply commit the file—new EOL markers and all.
The result of scenarios like these include wasted time and unnecessary modifications to committed files. Wasted time is painful enough. But when commits change every line in a file, this complicates the job of determining which of those lines were changed in a nontrivial way. Where was that bug really fixed? On what line was a syntax error introduced?
The solution to this problem is the svn:eol-style
property. When this property is set to a valid value, Subversion
uses it to determine what special processing to perform on the file so
that the file’s line-ending style isn’t flip-flopping with every commit
that comes from a different operating system. The valid values
are:
native
This causes the file to contain the EOL markers that are
native to the operating system on which Subversion was run. In
other words, if a user on a Windows machine checks out a working
copy that contains a file with an svn:eol-style
property set to native
, that file will contain CRLF
EOL markers. A Unix user checking
out a working copy that contains the same file will see LF
EOL markers in his copy of the
file.
Note that Subversion will actually store the file in the
repository using normalized LF
EOL markers regardless of the operating system. This is basically
transparent to the user, though.
CRLF
This causes the file to contain CRLF
sequences for EOL markers,
regardless of the operating system in use.
LF
This causes the file to contain LF
characters for EOL markers,
regardless of the operating system in use.
CR
This causes the file to contain CR
characters for EOL markers, regardless of the operating system
in use. This line-ending style is not very common.