リポジトリによる設定 — 第1部（全3部）：継承可能なプロパティ

この記事は、元の場所http://blogs.collab.net/subversion/the-road-to-repository-dictated-configuration-day-2-autopropsからの許可を得てミラーリングされています。無効なリンクは削除または更新されています。

著者：Paul Burba

投稿 2013-06-25

これは、リポジトリで設定できるさまざまな構成オプションについて説明する3部構成のシリーズの最初の記事です。

プロパティの継承

Subversionの最もカジュアルなユーザーでも、バージョン管理されたプロパティに精通している可能性があります。これらの名前と値のペアのメタデータは、ファイルまたはディレクトリに割り当てられます。「svn:」で始まる名前のプロパティの一部は、Subversion自体によって特別な意味が与えられ、特定の動作をトリガーしますが、残りはユーザーまたはサードパーティのSubversion関連ツールによる定義と解釈のために開かれています。

Subversion 1.7までは、バージョン管理されたプロパティは通常、設定されたファイルまたはディレクトリにのみ適用されていました。せいぜい、ディレクトリに設定されたプロパティは、ディレクトリの直下の子供に適用される場合があります1。たとえば、svn:ignoreプロパティは、ディレクトリに存在する場合、svn statusおよびその他のサブコマンドによって無視されるバージョン管理されていないファイルパターン（その同じディレクトリ内）のリストを定義します。

以降は、バージョン管理されたプロパティとリビジョンプロパティを区別せずに単に「プロパティ」について説明します。そのため、このブログシリーズ全体を通して、バージョン管理されたプロパティについて説明していることを覚えておいてください！リビジョンプロパティには、継承の概念がありません。

新しくリリースされたSubversion 1.8では、継承プロパティの概念が導入されています。この新しい機能は非常に透過的であり、実際には、これまでと同じようにプロパティを使用できます。これは、実際には「継承可能」なプロパティや「継承不可能」なプロパティというものは存在しないためです。— すべてのプロパティが潜在的に継承可能です！

1.8で実際に異なるのは、ワーキングコピーパス（またはURL）が与えられた場合、Subversionはそのパスの親に設定されたプロパティを見つけるメカニズムを持つようになったことです。これは、パスがワーキングコピーパスであり、パスの親がワーキングコピー内に見つからない場合でも機能します。このメカニズムは、svn proplistおよびsvn propgetサブコマンドの新しい--show-inherited-propsオプションで明らかになります。

簡単な例で、この新しいオプションの機能を示します。

注：今日の例では、無意味なカスタムプロパティを使用します。第2部と第3部では、実際に機能する新しいSubversion予約済みプロパティを示します。現時点では、新しいコアコンセプトをいくつか示したいだけです。

リポジトリのルートとさまざまなサブツリーにプロパティfooが設定されているとします。リポジトリのルートで再帰的なsvn propgetを実行することで、これらのプロパティ、それらの場所、および値をすべて表示できます2

1.8.0>svn pg foo http://svn.example.com/repos --verbose --recursive
Properties on 'http://svn.example.com/repos':
  foo
    bar
Properties on 'http://svn.example.com/repos/calc':
  foo
    baz
Properties on 'http://svn.example.com/repos/calc/trunk':
  foo
    qux
Properties on 'http://svn.example.com/repos/paint':
  foo
    fum
Properties on 'http://svn.example.com/repos/paint/trunk':
  foo
    zot

次に、リポジトリのサブツリー^/calc/trunkをチェックアウトします。

1.8.0>svn co http://svn.example.com/repos/calc/trunk calc-trunk-wc
A    calc-trunk-wc\doc
A    calc-trunk-wc\src
A    calc-trunk-wc\doc\INSTALL
A    calc-trunk-wc\FAQ
A    calc-trunk-wc\src\real.c
A    calc-trunk-wc\src\main.c
A    calc-trunk-wc\src\button.c
A    calc-trunk-wc\src\integer.c
A    calc-trunk-wc\Makefile
A    calc-trunk-wc\README
 U   calc-trunk-wc
Checked out revision 478.

当然のことながら、新しくチェックアウトされたワーキングコピーのルートでの再帰的なpropgetは、^/calc/trunkに対応するワーキングコピーパス上のfooプロパティのみを表示します。

1.8.0>svn pg foo calc-trunk-wc --verbose --recursive
Properties on 'calc-trunk-wc':
  foo
    qux

同じpropgetコマンドですが、今回は新しい--show-inherited-propsオプションを使用すると、ワーキングコピールートパス上の同じプロパティが表示されますが、そのパスのリポジトリの親上のfooプロパティも表示されます。

1.8.0>svn pg foo calc-trunk-wc --verbose --recursive --show-inherited-props
Inherited properties on 'calc-trunk-wc',
from 'http://svn.example.com/repos':
  foo
    bar
Inherited properties on 'calc-trunk-wc',
from 'http://svn.example.com/repos/calc':
  foo
    baz
Properties on 'calc-trunk-wc':
  foo
    qux

^/paintと^/paint/trunkに設定されたfooプロパティは、それらのパスがワーキングコピーの親ではないため表示されません。svn proplistサブコマンドも--show-inherited-propsオプションをサポートしており、同様の方法で機能しますが、もちろん、名前に関わらずすべての継承プロパティが表示されます。

構成要素

これで、再帰的なpropget/proplistの逆、つまりリポジトリツリーを「上」に調べる方法が得られました。「下」ではなく。「この新たに発見された能力で何ができるでしょうか？

1.8より前に存在していたすべてのSubversion予約済みプロパティは、設定されているパス、またはせいぜいそのパスの直下の子供にのみ適用されることに注意してください3。独自のリポジトリに追加したカスタムプロパティについても同様です。古いプロパティは、突然新しい範囲を持つようにはなりません。

その警告を脇に置いて、プロパティの継承は2つの場合に非常に役立ちます。

最初のケースは、継承を利用してプロパティを設定したパスの下のすべてのサブツリーにプロパティを適用する新しいSubversion予約済みプロパティ4です。このブログの第2部では、2つのそのようなプロパティの最初のもの、svn:auto-propsについて説明します。

2番目のケースは、バージョン管理されたプロパティに依存して動作を駆動する独自のツール、スクリプト、ワークフローなどです。それらのすべてについて、新しいツールが使えるようになりました。それをどのように使うかはあなた次第です。私たちが機能を開発したときには考えもしなかった、継承可能なプロパティの巧妙なアプリケーションを思いつく人がいるでしょう。

注意事項

今日の締めくくりとして、プロパティの継承に関するいくつかの点に注意する必要があります。

古いワーキングコピーのアップグレード

上記の例で、svn propget --show-inherited-props calc-trunk-wcによって、calc-trunk-wc上のプロパティと、リポジトリ内の親に設定されたプロパティの両方が表示されたことを思い出してください。Subversionは、リポジトリに接続せずに、この継承プロパティのルックアップを実行します5。これは、ワーキングコピーのルートのワーキングコピーデータベースに継承プロパティキャッシュを保持することによって行われます6。このキャッシュは、チェックアウト、更新、または切り替え中にワーキングコピーが更新されるたびに更新されます。「svn upgrade」コマンドを使用して古い形式のワーキングコピーをアップグレードすると、このキャッシュは作成されますが、設定されません。そのため、アップグレード後にはワーキングコピーを更新してください。

例：しまった、これは古いワーキングコピーです！

>svn pg foo --verbose --show-inherited-props
svn: E155036: Please see the 'svn upgrade' command
svn: E155036: The working copy at 'C:\SVN\calc-trunk-wc'
is too old (format 29) to work with client version '1.8.0 (r1490375)' (expects format 31). You need to upgrade the working copy first.

エラーメッセージに従ってワーキングコピーをアップグレードします。

>svn upgrade

継承されたプロパティを確認します。

>svn pg foo --verbose --show-inherited-props
Properties on '.':
  foo
    qux

ああ、そうです、キャッシュは更新によって設定する必要があります！

>svn up
Updating '.':
At revision 478.

これで、継承されたプロパティが見つかりました。

>svn pg foo --verbose --show-inherited-props
Inherited properties on '.',
from 'http://svn.example.com/repos':
  foo
    bar
Inherited properties on '.',
from 'http://svn.example.com/repos/calc':
  foo
    baz
Properties on '.':
  foo
    qux

最低限の要件

明らかに1.8 Subversionクライアントが必要ですが、1.8サーバーはオプションです。1.8サーバーは、継承プロパティキャッシュを設定する場合、またはURLに対してproplist/propgetサブコマンドを使用する場合に、より優れたパフォーマンスを提供する場合があります。

認証

読み取りアクセス権限を持つリポジトリパスからのみプロパティを継承できます。特定のパスへの読み取りアクセス権限がない場合、そのパスから継承するプロパティがないように見えます。このケースでは、警告またはエラーは発行されません。

ワーキングコピー内の継承

上記のように、継承プロパティキャッシュは、ワーキングコピーのルートが継承するプロパティのみを知っています。つまり、ローカルの変更や混合リビジョンワーキングコピーは、特定のワーキングコピーパスが継承する内容に影響しません。ここでその完全な影響について説明する場所ではありませんが、この簡単なルールを覚えておけば、驚きはありません。継承プロパティの最新値（たとえば、リポジトリのルートから）を確実に使用するには、ワーキングコピーのルートが最新であることを確認してください。

注記

  1. 熟練ユーザーは、Subversionにはディレクトリの直下の子要素よりも広い範囲に影響を及ぼすプロパティ、すなわちsvn:mergeinfoプロパティが既に存在することを指摘するかもしれません。もちろん、ご指摘の通りsvn:mergeinfoは継承可能ですが、これは独自の、十分に確立されたルールセットを持つ特殊なケースであり、「汎用的」な継承可能なプロパティに関するこの議論では無視して差し支えありません。↩

  2. ここでは、整形された出力を得るために--verboseオプションを使用しています。↩

  3. 再びsvn:mergeinfoを除いてのことです。↩

  4. Subversion 1.8.0 現在、Subversionが継承可能として解釈する予約済みのプロパティは、svn:auto-props（このブログの第2部で説明）とsvn:global-ignores（第3部で説明）のみです。今後のSubversionリリースでは、継承プロパティを用いた機能がさらに追加される予定です（ログメッセージテンプレートメカニズムなどが考えられます）。それまでは、自由にこの機能を使用してください。リポジトリ全体（またはその大きなサブセクション）に適用したいバージョン管理されたメタデータは、リポジトリのルート（または適切なサブツリー）のプロパティに簡単に格納できます。↩

  5. 一般的に、Subversionのワーキングコピーは、絶対に必要な場合にのみリポジトリにアクセスしようとします。これにより、リポジトリにアクセスできない場合でもワーキングコピーを使用できるようになり、その他の条件が同じであれば、リポジトリにアクセスする必要がないため、特定の操作が高速になる可能性があります。↩

  6. ワーキングコピー内のスイッチされたパスは、個別のワーキングコピールートとしてカウントされ、独自のキャッシュを持ちます。↩

著者について

ポール・バーバは、Apache Software FoundationのSubversionプロジェクトのコミッターであり、過去9年間Subversionに取り組んでいます。彼はニューハンプシャー州の自宅でCollabnetのソフトウェアエンジニアとして働いており、コーディングをしていないときは、甥っ子とスキーをしたり、友人とマウンテンバイクに乗ったり、妻と旅行したりしています。遠い昔、ポールはニューハンプシャー大学でビジネスの学位を取得しました。比較的最近、ボストン大学でコンピュータサイエンスの修士号を取得しました。