Subversionサーバーの拡張

この記事は、元の場所 https://www.open.collab.net/community/subversion/articles/EnhancingSubversionServer.html から許可を得てミラーリングされたものです。非アクティブなリンクは削除または更新されています。情報はSubversion 1.4時点のものであり、一部は現在のバージョンには適用されない場合があります。

オープンソースコミュニティまたは企業で、複数の関連プロジェクトのためにSubversionサーバーを管理する場合、効果的なコラボレーションに必要な程度に開発環境を標準化し、個々のチームがさまざまな方法で作業できる柔軟性を残すという、有用なバランスを保つ必要があります。個人やプロジェクトは、特定の機能やカスタマイズを定期的に要求します。この記事では、いつカスタマイズすべきか、どのようにカスタマイズすべきかについて議論し、そのような要求に対する推奨されるアプローチを提案します。

最初で最も重要な質問は、いつカスタマイズすべきかということです。多くのソフトウェアエンジニアやプロジェクトは、自分の好み、嫌い、必要に応じてツールや環境を適応またはカスタマイズする自然な傾向があります。彼らは特定のカスタマイズについて強く感じ、自分自身、プロジェクト、組織またはコミュニティ全体にとってのコストを適切に検討または定量化することなく、それらを強く求めます。カスタマイズが個人にのみ影響する場合、それは一人の問題と責任に過ぎないと主張できます。ただし、複数の人、プロジェクト、または組織全体に影響を与える場合は、メリットとコストのバランスを取る必要があります。

カスタマイズのコスト

明らかなコストは、カスタマイズを作成および維持するために必要な労力です。環境が進化するにつれて、作成、テスト、保守を行う必要があります。さらに、カスタマイズはデータへのアクセスしきい値を高めます。カスタマイズは、ツールやプラクティスの動作、ツールの使用を変更し、結果として、外部の人がプロジェクトを理解し、参加し、貢献することをより困難にします。また、ユーザーが問題が発生した場合、各カスタマイズをサポートする必要があります。言い換えれば、すべてのカスタマイズはサーバーの運用と保守をより高価にし、ユーザーが共同作業するためのしきい値を上げ、サポートする必要のある機能の多様性を増やします。

したがって、大多数のプロジェクトにとって具体的なメリットがあるか、または少数のプロジェクトにとって大きなメリットがある必要があります。前者は、カスタマイズというよりはむしろ、ユーザーが望む機能の要求（および初期プロトタイピング）であると言えます。後者は、大多数のユーザーにとって具体的すぎるカスタマイズであると言えます。

カスタマイズ方法

Subversionがすでに提供している機能を拡張するには、さまざまな方法があります。オプションは、クライアント側またはサーバー側のカスタマイズの2つのタイプに分類できます。

クライアント側 - ラッパー

クライアント側のカスタマイズは、サーバーが変更されず、コマンドラインクライアントまたはクライアント側のAPI呼び出しをラップすることによってクライアント側でカスタマイズが行われるソリューションです。クライアント側のカスタマイズは、カスタマイズの負担を要求する個人またはプロジェクトに委ね、要求者にカスタマイズが本当に望ましいか、または必要かどうかについて適切で正直な費用便益分析を強制します。また、ラッパーは、処理できるカスタマイズの数に関して非常にうまく拡張できます。ラッパーを維持する人の数はカスタマイズによって増減します。

クライアント側のカスタマイズの例としては、標準のSubversionコマンドラインクライアント上に構築されたPythonスクリプトであるsvnmerge.pyがあります。これにより、ユーザーはブランチとの間で変更を簡単にマージし、どの変更セットがすでにマージされたかを自動的に記録できます。マージされていない変更の常に更新されたリストを表示し、同じ変更を2回マージするなどのマージミスを防ぐことができます。 svnmerge.pyスクリプトは、現在Subversionの将来のリリースに向けて議論、設計、実装されているマージ追跡機能の初期プロトタイプです。

サーバー側 - フックスクリプト

サーバー側のカスタマイズは、サーバー構成が変更されるソリューションです。サーバー側のカスタマイズは、サーバー上のすべてのプロジェクトにカスタマイズを展開するという点で拡張されます。これらはサイトの日常的な運用に触れ、サービスの運用と保守の労力とコストを増加させます。また、サービスのセキュリティ、可用性、およびパフォーマンスに影響を与える可能性があります。

サーバー側のカスタマイズの主な例は、フックスクリプトです。フックまたはフックスクリプトは、新しいリビジョンの作成やバージョン管理されていないプロパティの変更など、リポジトリイベントによってトリガーされるプログラムです。各フックには、イベントの内容、操作対象のターゲット、イベントをトリガーしたユーザー名を知るための十分な情報が渡されます。フックの出力またはリターンステータスに応じて、フックプログラムはアクションを続行したり、停止したり、何らかの方法で中断したりする場合があります。 Subversionを使用したバージョン管理の書籍でこれについて詳しく説明しています。

Subversionは現在9つのフックを定義しています。


フックは、通常、3種類の機能に使用されます。


現時点では、Subversionは、サーバーがそのような変更をクライアントに伝え返す手段を持っていないため、コードがコーディングガイドラインに準拠することを自動的に保証するなど、事前処理または事後処理の機能を実行するフックをサポートしていないことに注意してください。言い換えれば、フックが何をするにしても、トランザクション自体を変更することはありません。代わりに、条件を確認してアクションを受け入れるか拒否することができます。

フックは、基本的にバージョン管理クライアントによるアクションに対応してサーバー上で任意のコードを実行する方法です。さらに、フックは一般にWebサーバーと同じ権限で実行され、それにより、同じサーバー上の他のリポジトリに影響を与える可能性があります。このメカニズムは非常に強力ですが、サーバーのセキュリティ、可用性、およびパフォーマンスに潜在的な影響があります。フックは、サーバーの速度を低下させたり、停止させたり、さらに悪いことに、リポジトリ内のデータを破損したりする可能性があります。

調査結果と推奨事項

複数のプロジェクトのためにSubversionサーバーを管理する場合、効果的なコラボレーションと効率的な運用を可能にするために環境を標準化することと、プロジェクトがさまざまな方法で作業するための十分な柔軟性を残すことの、有用なバランスを保つ必要があります。標準化は、プロジェクトを切り替えるときに環境を学習する時間を短縮したり、チーム間のより効果的なコラボレーションを可能にするなど、多くのメリットをもたらす可能性があります。ただし、今日の個人およびプロジェクトチームにおける異質性（ローカル文化、部門文化、プロセスなど）を考えると、すべてに適合するものは実現不可能でもあり、望ましくもありません。

技術的な観点から見ると、クライアント側とサーバー側のカスタマイズは、実行できることと実行できないことで異なります。


費用便益の観点からは、限られたユーザーセットに固有のカスタマイズをクライアント側に保持するようにしてください。これにより、カスタマイズの負担がプロジェクトに委ねられ、適切で正直な費用便益分析を行うことを促し、他のユーザーに影響を与えるのを防ぎます。大多数のプロジェクトに関連し、要求されている一般的なカスタマイズは、サーバー側の方が適しています。サーバー側のカスタマイズは、主にサーバー全体のパフォーマンス、可用性、およびセキュリティに影響を与える可能性があるため、通常、費用が大幅に高くなります。作成時とサーバーのアップグレードごとに厳密なテストが必要です。

特にフックを展開する場合は、リスクを軽減するため（フックが使用されるほどテストされる）、および標準化とカスタマイズの間で合理的なバランスを取るために、非常に一般的に使用されているフックのみを使用することを強くお勧めします。フックが人気があるのは、多くの人に価値を提供し、それによって努力する価値がある場合に限られます。難解なカスタマイズのリクエストは、作成、テスト、保守の努力に見合わない可能性があります。