svn:executable 属性は半自動的なやり方で バージョン管理されているファイルのファイルシステム上の実行 権限を制御するのに使われます。この属性は属性値を何も定義 しません—単に属性名が存在していれば、Subversionによって実行ビット が保存されます。この属性を削除すると、実行ビットの全制御は オペレーティングシステムに戻されます。

たくさんのオペレーティングシステム上で、コマンドとしてファイルを 実行できるかどうかは実行ビットの存在によって支配されています。 このビットは普通、デフォルトでは無効となっていて、必要に応じてユーザ が明示的に有効にしてやる必要があります。作業コピー中では、新しい ファイルが常に作られ、その一方で、更新処理を通じて存在している ファイルの新しいバージョンを受け取ります。これは、あるファイルの 実行ビットを有効にしてから作業コピーを更新した場合、もし更新処理の 一貫としてそのファイルが変更されたときにその実行ビットは無効になって しまう可能性があるということです。そこでSubversionは svn:executable 属性を、実行ビットを 有効にし続けるために用意しています。

この属性はFAT32やNTFSのように実行権限ビットの概念を持たないファイルシステム 上では何の効果もありません。 ^[32] また、それは定義された値を持ちませんが、Subversionはこの属性が設定される と、強制的にその値を*とします。最後に、この属性は ファイルに対してのみ有効で、ディレクトリに対しては意味を持ちません。

svn:mime-type 属性は、Subversionではいろいろな 目的に使われます。ファイル自身のMultipurpose Internet Mail Extensions (MIME) 上の分類の記憶場所で あると同時に、この属性の値はSubversion自身のいくつかの動作モードを 決定します。

たとえば、ファイルのsvn:mime-type 属性が非テキスト MIMEタイプである場合(例外はあるにせよ、一般的には、text/ 以外で始まるような場合)、Subversionはファイル内容はバイナリであると仮定 します—つまり、可読ではない—。この利点の一つは、Subversion が、作業コピー更新時に、サーバから受け取る変更点を、文脈に依存し行単位に マージする機能を提供することです。しかし、バイナリデータと信じられて いるファイルについては「行」のような概念はまったくありません。 それで、このようなファイルについては、Subversionは更新時に文脈マージを 実行しようとはしません。そのかわり、バイナリの作業コピーファイルを 修正し、それが更新される場合はいつでも、あなたのファイルは .orig 拡張子を付けた形に名称変更され、 それからSubversionは更新で受け取る変更を含むが、あなた自身のローカルな 修正は含んでいない新しい作業コピーファイルを、もとの名前で保存します。 この振る舞いは、文脈マージできないファイルに文脈マージを 実行しようとする間違った意図からユーザを守るためです。

また、もしsvn:mime-type属性が設定されていると、 SubversionのApacheモジュールはGET要求に応答するとき、HTTPヘッダの Content-type:にこの値を使います。これは ブラウザを使ってリポジトリを調べるときに、そのファイルをどうやって 表示すれば良いかの重要な手がかりになります。

svn:ignore 属性はある種のSubversion操作が無視する ファイルパターンのリストを含んでいます。多分もっともよく利用される 特殊属性で、global-ignores 実行時設定オプションと ともに利用されます。 (config項参照)。 それを使って、バージョン化されていないファイルとディレクトリを svn status、svn add、そして svn importコマンドの対象から除外します。

svn:ignore属性の背後にある理由は簡単に説明できます。 Subversionは、作業コピーディレクトリにあるすべてのファイルとサブディレクトリ がバージョン管理下にあるとは仮定しません。リソースはsvn add やsvn importコマンドを使って明示的にSubversion管理下に 置く必要があります。結果としてしばしば作業コピー中の多くのリソースが バージョン管理下にないことがあります。

svn status コマンドは出力の一部として作業コピーに あるバージョン化されていないファイルやサブディレトクリを、 global-ignores オプション(あるいはその組み込みの デフォルト値によって)によって、まだフィルタされていないものについてのみ表示します。 このように振る舞うのは、ユーザが、あるリソースをバージョン管理下に 追加するのを忘れたときに、そのことがわかるようにするためです。

しかしSubversionは無視すべきすべてのリソースの名前を推測できる わけではありません。さらに、非常によく、特定のリポジトリの、 すべての 作業コピー中で無視したいものが あったりします。そのリポジトリのすべてのユーザに、それぞれの実行時設定 領域に特定のリソースパターンを追加するように強いるのは、負担になる だけではなく、ユーザがチェックアウトした別の作業コピーの設定によって 壊れてしまう危険があります。

これを解決するには、あるディレクトリに現れるかも知れないリソースを 区別して無視できるようなパターンを、ディレクトリ自体に保存することです。 バージョン化されないリソースのよくある例で、基本的にはディレクトリごとに ユニークだが、現れることがあるのは、プログラムのコンパイルからの出力 などがあります。あるいは—この本自身を例にとれば—HTML, PDF, PostScriptファイルなどで、これらはあるDocBook XML入力ファイルを、もっと 読みやすい出力形式に変換した結果生成されるものです。

$ svn propset svn:ignore -F .cvsignore .
property 'svn:ignore' set on '.'
$

このような意味で、svn:ignore属性が解決法に なります。その値はファイルパターンの複数行のあつまりで、一行に 一つのパターンを書きます。属性は、パターンを適用したいと 思うディレクトリに設定されます。 ^[33] たとえば、svn statusからの以下の出力が あったとします:

$ svn status calc
 M     calc/button.c
?      calc/calculator
?      calc/data.c
?      calc/debug_log
?      calc/debug_log.1
?      calc/debug_log.2.gz
?      calc/debug_log.3.gz

この例では、button.cに対する何かの属性の 変更をしましたが、作業コピー中にはいくつかのバージョン管理して いないファイルもあります:ソースコードから コンパイルしたcalculator プログラム、 data.cという名前のソースコード、そして、 デバッグ出力のログファイルです。これで、ビルドシステムは常に calculatorを生成することを知っています。 ^[34] そして、テストプログラムは常にこのようなデバッグログファイルを 残すことも知っています。このような事実はあなたのだけではなく、 どの作業コピーにとっても正しいことです。そしてsvn status を実行するたびにこれらのファイルを見ることに興味があるのではないことも 知っています。それで、svn propedit svn:ignore calc を使っていくつかの無視パターンをcalc ディレクトリに 追加します。たとえばsvn:ignore 属性の新しい 値として、以下を追加するかも知れません:

calculator
debug_log*

この属性を追加すると、calcディレクトリ上に ローカルな属性変更を手に入れることができます。 しかし、svn status 出力について 何が変わったかに注意してください:

$ svn status
 M     calc
 M     calc/button.c
?      calc/data.c

これで、見たくないファイルが出力から全部消えました。 もちろんこのようなファイルはまだ作業コピーにあります。 Subversion はそれが存在していて、バージョン管理下にないことについて は何も言いません。これで、表示からつまらないファイルを全部取り除く 一方、もっと注意する必要のあるアイテムについてはそのままにします— たとえば、バージョン管理下に追加するのを忘れたソースコードファイル などは、依然として表示されます。

無視するファイルを見たい場合は、Subversionに --no-ignore オプションを渡すことができます:

$ svn status --no-ignore
 M     calc/button.c
I      calc/calculator
?      calc/data.c
I      calc/debug_log
I      calc/debug_log.1
I      calc/debug_log.2.gz
I      calc/debug_log.3.gz

無視されるパターンのリストはまたsvn add や svn importでも利用されます。これらの操作は Subversion にあるファイルやディレクトリの集まりを管理させることも 含まれます。ユーザがバージョン管理したいと思うファイルをツリー中 から明示的に選択させるかわりに Subversion は無視パターン規則を使って どのファイルバージョン管理システムから除外されるべきであるかを決定 します。この処理は再帰的なファイル追加処理やインポート処理の一環と して行なわれます。

Subversion はキーワードをファイル自身の内容と して置き換える機能があります—キーワードとは、バージョン化された ファイルについての役に立つ小さくて動的な情報です—。 キーワードは一般的にファイルが最後に修正された時刻についての情報を あらわしています。この情報はファイルが変更されるたびに変わり、さらに 重要なことにはファイルが変更された直後 に 変わるので、それはデータを完全に最新の状態に保つことは、バージョン管理 システム以外のどのような手段にとっても厄介なものです。編集した人間に まかせれば、その情報は必然的に古くなります。

たとえば、修正された最後の日付を表示したいと思っているドキュメントが あるとします。あなたは、そのドキュメントのすべての著者に、変更点を コミットする直前に、最後に変更された時刻を示す、ドキュメントの一部を ちょっとだけ変える作業を強いる必要がありますが、遅かれ早かれ誰かこれを忘れる人が 出てくるでしょう。 そうするかわりに、単にSubversionに対してLastChangedDate キーワードに対してキーワード置換を実行するように指示しましょう。 あなたはドキュメント中のkeyword anchor を置くこと でキーワードが挿入された、ファイル中の任意の場所を制御することができます。 このアンカー文字列は、単に$ KeywordName$のように書式化された 文字列です。

すべてのキーワードは大文字小文字の区別がありファイル中での 目印になります: キーワードが展開されるように大文字小文字を正しく 使う必要があります。 svn:keywords 属性の値 についても大文字小文字の区別を考慮すべきです — ある種の キーワードは大文字小文字を区別せずに解釈されますがこの仕様は 過去のものです。

Subversion は、置換可能なキーワードのリストを定義しています。 そのリストは、以下の五つのキーワードで、そのいくつかについては 別名を使うこともできます:

キーワードアンカーテキストをファイルに付け加えただけでは何も 起きません。明示的に要求しなければ Subversion は 決してテキスト置換をやろうとはしません。ようは、 キーワードのそのものの使い方についてのドキュメントを ^[35] 書いているときに、そのすばらしい例自身がSubversionに よって置換されてほしくはないでしょう。

Subversionが特定のファイルの上でキーワードを置換するかどうかを設定 するために、属性関連のサブコマンドに戻ります。 svn:keywords 属性は、バージョンファイルに設定 された場合は、そのファイルのどのキーワードが置換されるかの制御を します。その値は、空白で区切られたキーワード名称か別名のリストで、 前に書いたテーブルの中にあるもののどれかになります。

たとえば、weather.txt という名前の バージョン管理されているファイルがあり、以下のようだとします:

Here is the latest report from the front lines.
$LastChangedDate$
$Rev$
Cumulus clouds are appearing more frequently as summer approaches.

svn:keywords 属性がファイルに設定されていなければ Subversionは何も特別なことはしません。さて、 LastChangedDate キーワードの置換を有効にして みましょう。

$ svn propset svn:keywords "Date Author" weather.txt
property 'svn:keywords' set on 'weather.txt'
$

これで、weather.txt のローカル属性を変更しま した。そのファイルの内容には何の変化もないでしょう(属性を設定 する前に変更していなければ)。ファイルはキーワードアンカー Revキーワードを含んでいたとします。私たちはこの キーワードをまだ属性値として設定していません。Subversionはファイル に存在しないキーワードを置換する要求を無視しますし、 svn:keywords 属性値に存在しないキーワードを 置換することもありません。

この属性の変更をコミットした直後、Subversionは作業ファイルを、新しい 置換テキストで更新します。キーワードアンカー $LastChangedDate$を見るかわりに、置換結果を 見ることになるでしょう。この結果はキーワードの名前を含み、ドル記号 文字($) でくくられています。そして述べたように、 Rev は設定していないので、置換されませんでした。

svn:keywords 属性を「Date Author」 に設定してもキーワードの目印は$LastChangedDate$ の別名を使うのでやはりうまく展開されます。

Here is the latest report from the front lines.
$LastChangedDate: 2002-07-22 21:42:37 -0700 (Mon, 22 Jul 2002) $
$Rev$
Cumulus clouds are appearing more frequently as summer approaches.

もし誰か別の人がweather.txtに変更点をコミット すれば、ファイルのコピーは前と同じ置換されたキーワード値を表示し続ける でしょう—作業コピーを更新するまでは。そのとき、 weather.txtファイルのキーワードはそのファイルを コミットした一番最後の状態を反映する情報で置換されるでしょう。

バージョンファイルのsvn:mime-type 属性で 指定するのでなければ、Subversionはファイルは可読なデータが含まれている と仮定します。一般的に、Subversionはそのファイルに対する文脈差分を 報告することができるかどうかを決めるためにだけ利用します。そうで なければ、Subversionにとって、バイトはただのバイトでしかありません。

これは、デフォルトではSubversionはあなたのファイルが利用している 行端 (EOL)マーカ の種類に注意を向けないことを 意味します。不幸にも、異なるオペレーティングシステムはファイルのそれ ぞれの行末をあらわすのに別のトークンを使います。たとえば、普通Windows プラットフォームのソフトによって使われる行末トークンはアスキー制御文字 の組になります—キャリッジリターン(CR) と ラインフィード(LF) です。しかしUnixでは単に LF 文字を使って行末を表現します。

これらのオペレーティングシステムの上のさまざまなツールのすべてが 自分が実行されているオペレーティングシステムの もともとの行末スタイルending style とは違った形式の行末を含んでいるようなファイルを理解することができる わけではありません。よくある結果としては、Unixのプログラムは WindowsのファイルにあるCR 文字を通常の文字 (普通、^Mのように表示します)として扱い、Windows のプログラムはUnixファイルのすべての行を一つの巨大な行として連結 してしまいますが、これは行末を示すキャリッジリターン - ラインフィード 文字(あるいはCRLF)の組み合わせが見つかれらないため です。

この、別のEOLマーカに関する敏感さは、異なるオペレーティング システム間でファイルを共有しようとする人をいらいらさせます。 たとえば、ソースコードファイルと、このファイルをWindowsでも Unix でも編集する開発者を想像してみてください。もしすべての開発者 が常に行末を保存するようなツールを使うのであれば問題は起こりません。

しかし、実際には、たくさんのありふれたツールは別のEOLマーカのファイル を正しく読むことができないか、ファイルが保存されるときに、行末を そのオペレーティングシステム固有のものに変換してしまうかします。 もし開発者に最初のことが起こると、彼は外部の変換ユーティリティー (dos2unix や、それとペアになった unix2dos)を使ってファイル編集の前処理をしなくては なりません。あとの場合には何も特別の用意はいりません。しかし どちらの場合でも、すべての行が、最初のものと違ってしまいます。 変更をコミットする前に、ユーザには二通りの選択があります。 編集する前の行末スタイルと同じスタイルになるように変換ユーティリティー を使って修正したファイルを保存するか、単にそのファイルをコミットするか です—この場合、行末は新しいEOLマーカがつきます。

このようなシナリオの結果は時間の無駄と、コミットされたファイルに対する 不必要な修正になります。時間の無駄はそれだけで十分な苦痛です。しかし、 コミットがファイルのすべての行を変更するなら、これは、本当に修正された のはどの行なのかを決定する作業を非常に複雑なものにします。バグの修正は いったいどの行でなされたのか? どの行で構文エラーがあったのか?

この問題の解決は、svn:eol-style 属性です。 この属性が正しい値に設定されれば、Subversionはそれを使って、 どのような特殊な処理がファイルに必要であり、その処理をすれば ファイルの行末スタイルが、異なるオぺレーティングシステムからの コミットによって、ばたばた変化したりしないか、を決定します。 設定できる値は:

svn:externals 属性は一つ以上のチェックアウト されたSubversion作業コピーでバージョン管理されたディレクトリを 作るための命令を含んでいます。このキーワードに関するより詳しい情報 は外部定義項を見てください。

svn:special属性は svn:属性 のなかでユーザが直接設定したり修正することのできない唯一のものです。 Subversion はシンボリックリンクのような「特殊な(special)」 オブジェクトが追加の予告をされるときは常にこの属性を自動的に設定 します。リポジトリはsvn:specialオブジェクトを 通常のファイルのようにして保存します。しかしクライアントがこの属性 をチェックアウトあるいは更新中に見ようとすると、ファイルの内容を見て そのアイテムを特殊なオブジェクトと解釈します。いまこれを書いている時点 の Subversion のバージョンでは バージョン化されたシンボリックリンクだけがこの属性を持ちますが今後の Subversion ではおそらく他の特殊なノードもこの属性を持つことになるで しょう。

注意: Windows クライアントはシンボリックリンクを持たないのでリポジトリ から取得するファイルが、svn:specialによってシンボリッ クリンクであるとされていてもその属性は無視されます。Windows では ユーザは作業コピー中に通常のバージョン化されたファイルとしてこれを 受け取ることになります。

この属性はそのファイルが変数前にロックされるべきであることを 示すのに利用されます。属性の値は無関係です: Subversion はこの値を *に一律置き換えます。存在している場合、ファイル はユーザが明示的にファイルをロックしない限り、読み込むことだけが許され ます。ロックが取得できている場合(これは svn lock 実行の結果ですが)、ファイルは読み書き可能になります。ロックが解除 されるとファイルは再び読み込むことだけができる状態になります。

この属性がどのように、いつ、そしてなぜ有用なのかについての詳しい 情報は ロックのコミュニケーション項 を見てください。