属性

既に、Subversionがどのようにしてリポジトリ中にあるファルイやディレクトリの いろいろなバージョンを格納し、抽出するかを詳しく見てきました。 すべての章はSubversionというツールによって提供されているこの一番基本的な機能に ささげられてきました。そして、もしバージョン管理のサポートがそれで終わりだと しても、Subversionはバージョン管理の観点からは完全なものであったろうと思います。 しかし話にはまだ先があります。

ディレクトリとファイルのバージョン管理に加えて、Subversionは バージョン化されたファイル、ディレクトリに付随したバージョン化された メタデータの追加、修正、削除のためのインターフェースを用意しています。 このようなメタデータを属性と呼びます。属性は 作業コピー中のアイテムごとに、名前と名前に結びついた任意の値の組から なる二つの列を持つテーブルとして考えることができます。 一般的に、名前が人間が読むことのできるテキストでなくてはならないことを 除けば、名前と属性値は自由に選ぶことができます。そして属性に関する 一番重要なことは、属性もまた、ファイルの内容と同様にバージョン管理できる ということです。テキストの変更点をコミットするのと同じくらい簡単に 属性の変更を、修正したりコミットしたり、取り消したりすることができます。 そして、作業コピーを更新するときに、他の人がした属性変更についても 受け取ることができます。

この節では、属性をサポートするユーティリティーについて説明します— —Subversionのユーザと、Subversionそのものに対しての説明になります。 属性に関連したsvn サブコマンドを理解し、属性の変更が 通常のSubversionのワークフローにどう影響するかを学びます。Subversionの 属性はあなたのバージョン管理の経験を広げるものであることが、きっと わかるでしょう。

なぜ属性なんてものが?

属性は作業コピーにとても役に立つ情報を追加することができます。 実際、Subversion自身も特殊な情報を記録するのに属性を使っていて、 それはある特定の処理が必要になっていることを示すようなときに 使っています。同様に、ユーザは自分自身の目的のためにも属性を使う ことができます。もちろん属性でできることはすべて、バージョン化 したファイルでもできるのですが、まずは以下のようなSubversion属性の 使い方の例を見てください。

あなたは、たくさんのデジタル写真を見せるためのウェブサイトを設計していて、 タイトルと日付を付けて表示したいとします。ここで、写真の内容は常に 変化するので、このサイトの管理をできる限り自動化したいと思っています。 それぞれの写真は非常に大きいので、このような場合の常套手段として あなたはサイトをおとずれた人に小さなサムネイルの画像を用意したいとします。 これを普通のファイルでやることもできます。つまり、ディレクトリに image123.jpgimage123-thumbnail.jpg の両方を置けば良いのです。あるいは両方のファイル名称を一緒にして、 別ディレクトリにおいてもいいですね。 thumbnails/image123.jpgのような感じです。 タイトルと日付についても同様の方法をとることができ、これもまた、もとの 画像ファイルとは別のものになります。すぐ、ファイルのツリーはごちゃごちゃ になり、新しい写真がサイトに追加されるたびに、サイトのデータは何倍にも 膨れ上がります。

Subversionのファイル属性を使った同じ設定を考えてみましょう。 ある画像ファイルimage123.jpgと、そのファイル の属性として設定するcaptiondatestamp, そして thumbnailがあるところを想像して ください。こうすれは、作業コピーのディレクトリはもっと管理しやすく なります—実際これで画像ファイル以外の何もないように 見えます。しかし、あなたの自動スクリプトはもっと多くのことを 知っています。それはsvn (あるいはさらに、 Subversion言語連携を使うこともできます—「C と C++以外の言語の利用」 参照) を使って拡張情報を追加しますが、それはあなたのサイトが、 インデックスファイルを読んだり、 複雑なファイルパス操作の仕組みをいじることなしに、表示する必要がある ものです。

Subversionの属性をどう使うかはあなたしだいです。既に指摘した ように、Subversionは自分自身が使う属性を持っていて、この章のあとで 少し説明します。しかし、まずは、svn プログラム を使って、どのように属性を操作するかを考えましょう。

属性の操作

svn コマンドにはファイルとディレクトリの属性 を追加したり修正したりするいくつかの方法があります。短い可読な属性を 新規に追加する一番簡単な方法は属性の名前と値をpropset サブコマンドで指定することです。

$ svn propset copyright '(c) 2003 Red-Bean Software' calc/button.c
property 'copyright' set on 'calc/button.c'
$

しかし、属性値に対してSubversionが持つ柔軟性については既にさんざん 言ってきました。もし、複数行テキスト、またはバイナリ値を属性値に したいと考えているなら、コマンドラインからその値を入力したくはないと 思います。それでpropset サブコマンドは --file(-F) オプションを使って、新しい属性値が入った ファイルの名前を指定することもできます。

$ svn propset license -F /path/to/LICENSE calc/button.c
property 'license' set on 'calc/button.c'
$

属性で利用できる名前にはいくつかの制限があります。属性の名前は 文字、コロン(:) あるいはアンダースコア(_) で始まり、その後では数字、ハイフン(-)、ピリオド(.) も使えます。 [31]

propset コマンドに加えて、svn プログラムはpropedit コマンドも用意しています。 このコマンドは、設定されたエディタを使って(「config」参照) 属性を追加したり修正したりします。 このコマンドを実行するとsvn は現在の属性値を書き込んだ 一時ファイルを作ってエディタを起動します。(新しい属性を追加する場合は これは空になります)。それから、自分が望むような値になるまで新しい属性値 をエディタを使って修正し、一時ファイルを保存してからエディタを抜けます。 Subversionは属性の値が変更されたことを確認すると、それを新しい属性値 として受け入れます。もしエディタを変更することなく抜ければ、属性値の 変更は起こりません。

$ svn propedit copyright calc/button.c  ### exit the editor without changes
No changes to property 'copyright' on 'calc/button.c'
$

他のsvnコマンドと同様に、属性に関するこれらの コマンドも複数パスに対して一度に実行することができます。これは 一つのコマンドで複数のファイル上の属性を修正することを可能にします。 たとえば、以下のようなことができます:

$ svn propset copyright '(c) 2002 Red-Bean Software' calc/*
property 'copyright' set on 'calc/Makefile'
property 'copyright' set on 'calc/button.c'
property 'copyright' set on 'calc/integer.c'
…
$

このような属性の追加や編集は、保管されている属性値を簡単に取得 できないなら、あまり便利ではありません。それで svn プログラムはファイルやディレクトリに保管された 属性の名前と値を表示するためのサブコマンドを二つ用意しています。 svn proplistはパス上に存在する属性の名前の一覧を 表示します。ノード上の属性名がわかってしまえば、個別に svn propgetを呼び出してその属性値を要求することが できます。このコマンドは与えられた(一つ以上の)パスと属性名 から、その属性値を標準出力に表示します。

$ svn proplist calc/button.c
Properties on 'calc/button.c':
  copyright
  license
$ svn propget copyright calc/button.c
(c) 2003 Red-Bean Software

proplist コマンドの変種として、すべての属性の 名前と値の両方をリストするものがあります。これには単に、 --verbose(-v) オプションを指定すればOKです。

$ svn proplist --verbose calc/button.c
Properties on 'calc/button.c':
  copyright : (c) 2003 Red-Bean Software
  license : ================================================================
Copyright (c) 2003 Red-Bean Software.  All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions 
are met:

1. Redistributions of source code must retain the above copyright
notice, this list of conditions, and the recipe for Fitz's famous
red-beans-and-rice.
…

最後の属性関連サブコマンドは propdelです。Subversionは空の値を持つ属性を 格納することを許すので、propeditpropsetを使うだけでは、属性を削除することが できません。たとえばこのコマンドは期待される結果にはなりません :

$ svn propset license '' calc/button.c
property 'license' set on 'calc/button.c'
$ svn proplist --verbose calc/button.c
Properties on 'calc/button.c':
  copyright : (c) 2003 Red-Bean Software
  license : 
$

属性の削除にはpropdel コマンドを使う必要が あります。構文は他の属性関連コマンドとよく似ています:

$ svn propdel license calc/button.c
property 'license' deleted from 'calc/button.c'.
$ svn proplist --verbose calc/button.c
Properties on 'calc/button.c':
  copyright : (c) 2003 Red-Bean Software
$

これで、属性関連のsvn サブコマンドのすべてに ついて説明したので、日常的なSubversionワークフローに、属性の変更 がどのような影響を与えるかを見てみましょう。前に指摘したように ファイルとディレクトリの属性は、普通のファイルの内容と同様、 バージョン化されます。結果として、Subversionは他の人がした修正点を 自分自身の上にマージすることができます。—もちろん通常の マージと同様、うまくいくかも知れませんし、衝突するかも知れません。

そしてファイルの中身の場合と同じように、属性の変更はローカルな 修正にしかすぎず、svn commitでリポジトリに コミットして初めて修正が確定します。変更はやはり簡単に取り消す こともできます—svn revert コマンドは ファイルやディレクトリを編集前の状態に戻し、その内容、属性、 などすべてについてもそうです。さらに、 svn statussvn diff コマンドを使って、ファイルやディレクトリ属性の状態について 有用な情報を受け取ることができます。

$ svn status calc/button.c
 M     calc/button.c
$ svn diff calc/button.c
Property changes on: calc/button.c
___________________________________________________________________
Name: copyright
   + (c) 2003 Red-Bean Software

$

status サブコマンドがM を最初のコラムではなく、二番目のコラムに表示するのに注意です。 これは、calc/button.cの属性を修正したが、 ファイルの内容は変更していないことを示しています。 属性も内容も変更すれば、M は、最初のコラム にも二番目のコラムにも表示されます。 (svn status参照)。

Subversionが現在の属性の差異を表示する標準的でない方法に 気づかれたかも知れません。 svn diff を実行して、出力をパッチファイルを 作るためにリダイレクトすることができます。patch プログラムは属性にたいするパッチを無視します—一般的に それは理解できないゴミをすべて無視します。これは不幸にも svn diffで生成されたパッチを完全に適用するには、 属性の修正については手で適用しなくてはならないということを意味します。

見たように、属性の修正は典型的なSubversionのワークフローにはあまり 大きな影響を与えません。作業コピーを更新し、ファイルとディレクトリの 状態をチェックし、自分のした変更点について報告し、そのような修正点を リポジトリにコミットするという一般的なパターンは属性の存在や非存在 とは完全に無関係です。 svnプログラムにはいくつかの 追加のサブコマンドがあり、実際に属性変更することができます。 しかし、それは、属性関連コマンドの目に見える唯一の非対象性です。

特殊な属性

Subversionは属性について特別のポリシーを持っていません—どのような 目的にも使うことができます。Subversionは、svn:という プレフィックスの付いた属性名を使うのを禁じているだけです。これが、 Subversion自身が使う属性の名前空間です。実際、Subversionは、ファイルや ディレクトリに特殊な効果をおよぼすようなある種の属性を定義しています。 この節ではこの神秘をときあかし、どうやってこれら特殊な属性が、あなたの Subversionライフをちょっとだけ楽にするかについて説明します。

svn:executable

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

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

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

svn:mime-type

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

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

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

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

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

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

このような意味で、svn:ignore属性が解決法に なります。その値はファイルパターンの複数行のあつまりで、一行に 一つのパターンを書きます。属性は、パターンを適用したいと 思うディレクトリに設定されます。 [34] たとえば、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を生成することを知っています。 [35] そして、テストプログラムは常にこのようなデバッグログファイルを 残すことも知っています。このような事実はあなたのだけではなく、 どの作業コピーにとっても正しいことです。そして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 addsvn importでも利用されます。これらの操作は Subversion にあるファイルやディレクトリの集まりを管理させることも 含まれます。ユーザがバージョン管理したいと思うファイルをツリー中 から明示的に選択させるかわりに Subversion は無視パターン規則を使って どのファイルバージョン管理システムから除外されるべきであるかを決定 します。この処理は再帰的なファイル追加処理やインポート処理の一環と して行なわれます。

svn:keywords

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

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

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

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

Date

このキーワードはファイルがリポジトリ中で修正された最後の時刻 をあらわし、$Date: 2002-07-22 21:42:37 -0700 (Mon, 22 Jul 2002) $のようなものです。これは LastChangedDateと指定することもできます。

Revision

このキーワードは、ファイルがリポジトリで変更された最後のリビジョン をあらわし、$Revision: 144 $のようなものです。これは LastChangedRevisionまたは Revと省略することもできます。

Author

このキーワードはリポジトリ中のこのファイルを最後に変更したユーザ をあらわし、$Author: harry $のようなものです。これは LastChangedByと省略することもできます。

HeadURL

このキーワードはリポジトリ中のファイルの最後のバージョン に対する完全なURLをあらわし、 $HeadURL: http://svn.collab.net/repos/trunk/README $ のようなものです。これはURLと省略する こともできます。

Id

このキーワードは、他のキーワードの圧縮された組み合わせです。 その置き換えは、 $Id: calc.c 148 2002-07-28 21:30:43Z sally $のようなもので、ファイル calc.c が最後に変更されたのは リビジョン148 で、時間は July 28, 2002 の夜、変更した人は、 sallyであることを意味しています。

キーワードアンカーテキストをファイルに付け加えただけでは何も 起きません。明示的に要求しなければ Subversion は 決してテキスト置換をやろうとはしません。ようは、 キーワードのそのものの使い方についてのドキュメントを [36] 書いているときに、そのすばらしい例自身が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:eol-style

バージョンファイルの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はそれを使って、 どのような特殊な処理がファイルに必要であり、その処理をすれば ファイルの行末スタイルが、異なるオぺレーティングシステムからの コミットによって、ばたばた変化したりしないか、を決定します。 設定できる値は:

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は実行する ことさえできませんが)

svn:externals

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

svn:special

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

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

svn:needs-lock

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

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

属性の自動設定

属性は Subversion での強力な機能で、この章や別の章で議論さ れるたくさんの Subversion の機能の重要な部品として振舞います— テキスト形式の diff やマージのサポート、キーワード置換、改行変換、など です。しかし属性機能を完全に使いこなすには、正しいファイルやディレクト リに設定する必要があります。残念なことに、このステップはきまりきった作 業の中で簡単に忘れられてしまいますが、それは属性の設定し忘れは通常 はっきりしたエラーを起こすことがないからです(少なくても、そう、例えば バージョン管理システムにファイルを追加するのと比較すれば)。必要な場所 で属性が設定されるのを助けるため Subversion は単純ではありますが役に立 つ機能を提供しています。

svn addまたはsvn importであるファイルをバージョン管理下に置くばあい、 Subversion はそのファイルが人間によって読めるものか読めないものかを 非常に基本的な方法で決定します。もし読めないファイルであった場合、 Subversion は自動的にそのファイルのsvn:mime-type 属性をapplication/octet-streamに設定します (これは一般的なこれはバイトの集まりですよというMIME タイプになります)。もちろん Subversion が間違った推測をするか、より 正確なsvn:mime-type属性を設定したい場合— 多分image/pngとか、 application/x-shockwave-flashとか—属性を 削除したり編集したりすることは常に可能です。

Subversion はまた自動属性機能を提供しますが、これはファイ ル名のパターンによって適切な属性名と属性値を設定できるようにするもので す。この規則は実行時設定領域に設定します。やはりファイルの追加やインポー トに影響を与え、この操作中で Subversion が決定するデフォルトの MIME タ イプを上書きするだけではなく、Subversion や固有の追加属性を設定するこ ともできます。たとえば、JPEG ファイルを追加する時には常に— *.jpgというパターンに当てはまるファイルを追加する時 には常に—Subversion は自動的にsvn:mime-type 属性をimage/jpegに設定する、といった具合です。 あるいはまた*.cppに当てはまるすべてのファイルには svn:eol-style属性をnativeに設定 し、svn:keywords属性をIdに設定 する、といった具合です。自動属性のサポートはおそらくSubversion 関連 ツール中で最も手軽に扱うことのできる性質です。この設定に関連した詳細は 「config」を見てください。




[31] XML に詳しいのであれば、これは XML "名称" の ASCII サブセットな構文 に近いものです。

[32] コミットログ中の、スペルミス、文法間違い、 つまらないミス は多分--revprop オプション利用で一番よく起こるものです。

[33] Windowsのファイルシステムはファイル拡張を使ってそれが実行ファイルである ことを示します。(.EXE, .BAT, .COMのような拡張子です)

[34] パターンはそのディレクトリのみに制限されます—サブディレクトリに 再帰的に伝わることはありません。

[35] それがビルドシステムの核心では?

[36] … あるいは、その本の一節を…