Fortunately for Subversion users who routinely find themselves on different computers with different operating systems, Subversion's command-line program behaves almost identically on all those systems. If you know how to wield svn on one platform, you know how to wield it everywhere.
However, the same is not always true of other general classes of software, or of the actual files you keep in Subversion. For example, on a Windows machine, the definition of a «text file» would be similar to that used on a Linux box, but with a key difference—the character sequences used to mark the ends of the lines of those files. There are other differences, too. Unix platforms have (and Subversion supports) symbolic links; Windows does not. Unix platforms use filesystem permission to determine executability; Windows uses filename extensions.
Because Subversion is in no position to unite the whole world in common definitions and implementations of all of these things, the best it can do is to try to help make your life simpler when you need to work with your versioned files and directories on multiple computers and operating systems. This section describes some of the ways Subversion does this.
Subversion joins the ranks of the many applications which
recognize and make use of Multipurpose Internet Mail
Extensions (MIME) content types. Besides being a
general-purpose storage location for a file's content type,
the value of the svn:mime-type file
property determines some behavioral characteristics of
Subversion itself.
For example, one of the benefits that Subversion typically
provides is contextual, line-based merging of changes received
from the server during an update into your working file. But
for files containing non-textual data, there is often no
concept of a «line». So, for versioned files
whose svn:mime-type property is set to a
non-textual MIME type (generally, something that doesn't begin
with text/, though there are exceptions),
Subversion does not attempt to perform contextual merges
during updates. Instead, any time you have locally modified a
binary working copy file that is also being updated, your file
is renamed with a .orig extension, and
then Subversion stores a new working copy file that contains
the changes received during the update, but not your own local
modifications, at the original filename. This behavior is
really for the protection of the user against failed attempts
at performing contextual merges on files that simply cannot be
contextually merged.
Also, if the svn:mime-type property is
set, then the Subversion Apache module will use its value to
populate the Content-type: HTTP header when
responding to GET requests. This gives your web browser a
crucial clue about how to display a file when using it to
peruse your Subversion repository's contents.
На многих операционных системах возможность выполнения файла
как команды определяется битом разрешения выполнения. Обычно по
умолчанию этот бит не установлен и для файлов которым это
необходимо, он должен быть явно установлен пользователем.
Однако слишком сложно помнить какие именно файлы в только что созданной
рабочей копии должны иметь установленный бит выполнения, и
устанавливать этот бит. Для таких случаев Subversion предлагает
использовать свойство svn:executable, как способ
показать для каких файлов бит исполнения должен быть установлен, а
Subversion в свою очередь, при создании рабочей копии самостоятельно
обрабатывает такой запрос для подобных файлов.
Это свойство не имеет ни какой силы на таких файловых
системах, как FAT32 и NTFS, не имеющих понятия бита разрешения
выполнения[16]. Кроме того,
так как оно не имеет определенного значения, при его установке
Subversion принудительно устанавливает значение
*. Наконец, это свойство действительно только
для файлов, не для директорий.
Unless otherwise noted using a versioned file's
svn:mime-type property, Subversion
assumes the file contains human-readable data. Generally
speaking, Subversion only uses this knowledge to determine
if 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
are prepared to 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. Common results are that Unix programs
treat the CR character present in Windows
files as a regular character (usually rendered as
^M), and that Windows programs combine
all of the lines of a Unix file into one giant line because
no carriage return-linefeed (or CRLF)
character combination was found to denote the end of
line.
This sensitivity to foreign EOL markers can become frustrating for folks who share a file across different operating systems. For example, consider a source code file, and developers that edit this file on both Windows and Unix systems. If all the developers always use tools which 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 they 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 non-trivial 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:
nativeThis 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 which 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.
CRLFThis causes the file to contain
CRLF sequences for EOL markers,
regardless of the operating system in use.
LFThis causes the file to contain
LF characters for EOL markers,
regardless of the operating system in use.
CRThis 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. It was used on older
Macintosh platforms (on which Subversion doesn't even
run).