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 that 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 nontextual data,
there is often no concept of a “line.” So, for versioned files
whose svn:mime-type
property is set to a nontextual 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
left untouched and Subversion creates two new files. One file has a
.oldrev
extension and contains the BASE revision of the
file. The other file has a .newrev
extension and
contains the contents of the updated revision of the file. 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.
警告 | |
---|---|
The |
Subversion provides a number of mechanisms by which to automatically set the
svn:mime-type
property on a versioned file. See 第 3.4 节 “自动设置属性” for details.
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 you use it to peruse your Subversion repository's contents.
On many operating systems, the ability to execute a file as a command is
governed by the presence of an execute permission bit. This bit usually
defaults to being disabled, and must be explicitly enabled by the user for
each file that needs it. But it would be a monumental hassle to have to
remember exactly which files in a freshly checked-out working copy were
supposed to have their executable bits toggled on, and then to have to do
that toggling. So, Subversion provides the
svn:executable
property as a way to specify that the
executable bit for the file on which that property is set should be enabled,
and Subversion honors that request when populating working copies with such
files.
This property has no effect on filesystems that have no concept of an
executable permission bit, such as FAT32 and NTFS.[15] Also, although it has no defined values, Subversion
will force its value to *
when setting this property.
Finally, this property is valid only on files, not on directories.
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-linefeed (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, and developers that 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
这会导致这个文件使用CRLF
序列作为EOL标志,不管使用何种操作系统。
LF
这会导致文件使用LF
字符作为EOL标志,不管使用何种操作系统。
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.