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 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.
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 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.
この属性は、FAT32 や NTFS のように実行権ビットの概念を持たないファイルシステムでは何の効果もありません。[12]また、この属性は定義された値を持ちませんが、Subversion はこの属性が設定されると、強制的にその値を * とします。最後に、この属性はファイルに対してのみ有効で、ディレクトリに対しては意味を持ちません。
バージョンファイルのsvn:mime-type 属性で 指定するのでなければ、Subversionはファイルは可読なデータが含まれている と仮定します。一般的に、Subversionはそのファイルに対する文脈差分を 報告することができるかどうかを決めるためにだけ利用します。そうで なければ、Subversionにとって、バイトはただのバイトでしかありません。
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 which preserve the line ending style of the file, no problems occur.
しかし、実際には、たくさんのありふれたツールは別のEOLマーカのファイル を正しく読むことができないか、ファイルが保存されるときに、行末を そのオペレーティングシステム固有のものに変換してしまうかします。 もし開発者に最初のことが起こると、彼は外部の変換ユーティリティー (dos2unix や、それとペアになった unix2dos)を使ってファイル編集の前処理をしなくては なりません。あとの場合には何も特別の用意はいりません。しかし どちらの場合でも、すべての行が、最初のものと違ってしまいます。 変更をコミットする前に、ユーザには二通りの選択があります。 編集する前の行末スタイルと同じスタイルになるように変換ユーティリティー を使って修正したファイルを保存するか、単にそのファイルをコミットするか です—この場合、行末は新しいEOLマーカがつきます。
このようなシナリオの結果は時間の無駄と、コミットされたファイルに対する 不必要な修正になります。時間の無駄はそれだけで十分な苦痛です。しかし、 コミットがファイルのすべての行を変更するなら、これは、本当に修正された のはどの行なのかを決定する作業を非常に複雑なものにします。バグの修正は いったいどの行でなされたのか? どの行で構文エラーがあったのか?
この問題の解決は、svn:eol-style 属性です。 この属性が正しい値に設定されれば、Subversionはそれを使って、 どのような特殊な処理がファイルに必要であり、その処理をすれば ファイルの行末スタイルが、異なるオぺレーティングシステムからの コミットによって、ばたばた変化したりしないか、を決定します。 設定できる値は:
nativeこれは、ファイルが、Subversionが実行されているオペレーティング システムの本来のEOLマーカを含むようにします。言い換えると もしWindows上のユーザが作業コピーをチェックアウトして、そこには svn:eol-style 属性がnative に設定されたファイルがある場合、そのファイルはCRLF EOLマーカを含むということです。逆にUnix ユーザが作業コピーをチェック アウトし、そこに、その同じファイルがあった場合は、ファイルのコピー にはLF EOLマーカが含まれることになります。
Subversionは実際にはリポジトリにファイルを格納するときには、 オペレーティングシステムにはよらず、正規化されたLF EOLマーカを使います。これは基本的にユーザには意識しなくても良いように なっているわけですが。
CRLFこれは使っているオペレーティングシステムによらず、ファイルのEOLマーカ にCRLF の並びを使います。
LFこれは使っているオペレーティングシステムによらず、ファイルのEOLマーカ にLF 文字を使います。
CRこれは使っているオペレーティングシステムによらず、ファイルのEOLマーカ にCR 文字を使います。 この行末スタイルはそれほど一般的ではありません。それは古いMacintosh プラットフォームで利用されていました。(その上ではSubversionは実行する ことさえできませんが)