Subversion同很多應用一樣利用多用途網際郵件擴展(MIME)內容類型，svn:mime-type屬性為Subversion的許多目的服務，除了保存一個文件的MIME分類以外，這個svn:mime-type屬性值也描述了一些Subversion自己使用的行為特性。

舉個例子，一個好處就是Subversion在更新時通常可以提供基於上下文的行為基礎的合併，如果一個文件svn:mime-type屬性設定為非文字的MIME類型(通常是那些不是text/開頭的類型，但也有例外)，Subversion會假定這個文件保存了二進制內容—也就是不可讀的資料。一個好處就是Subversion通常在更新工作副本時提供了一個前後相關的以行為基礎的修改合併，但是對於二進制資料文件，沒有「行」的概念，所以對這些文件，Subversion不會在更新時嘗試執行合併操作，相反，任何時候你在本地已經修改的一個二進制文件有了更新，你的文件擴展名會修改為.orig，然後Subversion保存一個新的工作副本文件來保存更新時得到的修改，但原來的文件名已經不是你自己的本地修改。這個行為模式是用來保護用戶在對不可文字合併的文件嘗試執行文字的合併時失敗的情形。

另外，如果設定了svn:mime-type屬性，Subversion的Apache模塊會使用這個值來在HTTP頭裡輸入Content-type:，這給了web瀏覽器如何顯示版本庫的一個文件提供了至關重要的線索。

在多數操作系統，執行一個文件或命令的能力是由執行位管理的，這些位預設是關閉的，必須由用戶根據需要顯式的指定，但是記住應該為哪些檢出的文件設定可執行位會是一件很麻煩的事情，所以Subversion提供了svn:executable這個屬性來保持打開執行位，在工作副本得到這些文件時設定執行位。

這個屬性對於沒有可執行權限位的文件系統無效，如FAT32和NTFS。 ^[12]也就是說，儘管它沒有定義的值，在設定這個屬性時，Subversion會強制它的值為*，最後，這個屬性只對文件有效，目錄無效。

除非使用版本化文件的svn:mime-type屬性註明，Subversion會假定這個文件保存了可讀的資料，一般來講，Subversion只使用這些訊息來判斷一個文件是否可以用上下文區別的報告，否則，對Subversion來說只是字節。

這意味著預設情況下，Subversion不會關注任何行結束標記(end-of-line，EOL)，不幸的是不同的操作系統在文字文件使用不同的行結束標誌，舉個例子，Windows平台下的A編輯工具使用一對ASCII控制字元—回車(CR)和一個換行(LF)，而Unix軟體，只使用一個LF來表示一個行的結束。

並不是所有操作系統的工具準備好了理解與本地行結束樣式不一樣的行結束格式，一個常見的結果是Unix程序會把Windows文件中的CR當作一個不同的字元(通常表現為^M)，而Windows程序會把Unix文件合併為一個非常大的行，因為沒有發現標誌行結束的回車加換行(或者是CRLF)字元。

對外來EOL標誌的敏感會讓在多種操作系統分享文件的人們感到沮喪，例如，考慮有一個原始碼文件，開發者會在Windows和Unix系統上編輯這個文件，如果所有的用戶使用的工具可以展示文件的行結束，那就沒有問題了。

但實踐中，許多常用的工具不會正確的讀取外來的EOL標誌，或者只是在保存文件時將文件的行結束符轉換為本地的樣式，如果是前者，他需要一個外部的轉換工具(如dos2unix，或是他的伴侶unix2dos)來準備需要編輯的文件。後一種情況不需要額外的準備工作，兩種方法都會造成文件會與原來的文件在每一行上都不一樣！在提交之前，用戶有兩個選擇，或者選擇用一個轉換工具恢復文件的行結束樣式，或者是簡單的提交文件—包含新的EOL標誌。

這個情景的結局看起來像是要浪費時間對提交的文件作不必要的修改，浪費時間是痛苦的，但是如果提交修改了文件的每一行，判斷文件修改了哪一行會是一件複雜的工作，bug在哪一行修正的？哪一行導致了語法錯誤？

這個問題的解決方案是svn:eol-style屬性，當這個屬性設定為一個正確的值時，Subversion使用它來判斷針對行結束樣式執行何種特殊的操作，而不會隨著多種操作系統的每次提交而發生劇烈變化，正確的值有：