svk - Subversion を用いた分散バージョン管理システム

Subversion は、 オープンソースのソースコードのバージョン管理システムとして多く利用されています。

svk は、 Subversion のファイルシステムを用いて、 分散バージョン管理システムの機能を提供しています。

Subversion のクライアントは、 リモートにある Subversion のサーバーとだけ、 データの同期をとることができます。 svk は、リモートの Subversion のリポジトリだけでなく、 CVS や Perfoce などの他のバージョン管理システムと同期することができます。

つまり、バックエンドのバージョン管理システムの違いを意識することなく、 複数のバージョン管理システムを統一的に扱うことができます。 また、ローカルにリポジトリを持つことで、 コミット権限のないリポジトリに対しても、 手元で行った変更などを履歴管理することができるようになります。

動作モデル

svk のサーバーは、各クライアント上で動作します。 ユーザーは、 ローカルで動作しているサーバーに対して svk のクライアントから操作を行います。 この点だけをみれば、 Subversion や CVS のサーバーがローカルで動作していて、 それらのリポジトリを subversion や cvs のクライアントで操作していること同じです。

svk のサーバーは、 さらに上位のバージョン管理システムのクライアントとしても動作します。 つまり、 本来のバージョン管理システムとクライアントの中間にsvkのクライアントが位置することで、 バージョン管理システムのミドルウェア的な存在になり、 各バージョン管理システムの違いを吸収します。

上位サーバーにコミット権限がある場合は、 svk のサーバーにコミットしたものは、 上位のサーバーにも反映されます。 上位サーバーへのコミット権限がない場合でも、 上位サーバーからのデータのミラーリングはできますが、 ローカルで行った変更は svk のサーバーにだけ反映されます。 svk の内部でも履歴管理が行われているため、 ファイルの履歴を参照したり、 古いバージョンのファイルに戻すことができるようになります。

メリット

アリエル・ネットワークでは、 最近のプロジェクトではバージョン管理システムに Subversion を使用しています。

しかし、古いプロジェクトでは、 プロジェクトの発足当時は Subversion がまだ安定していなかったため、 CVS を利用して、バージョン管理を行っています。

現状は、 Subversion と cvs の2つのバージョン管理システムを併用している状態です。 各クライアントで svk を動作させることで、 Subversion と cvs の2つのシステムの違いを意識することなくバージョン管理ができるようになります。

また、 自社開発のプロダクト以外にも、 多くのオープンソースのプロダクトを利用しています。

こうしたプロダクトには、 バージョン管理システムへのコミット権限を持っていません。 プロダクトをそのまま利用するだけなら特に問題は発生しませんが、 いくつかのプロダクトでは独自のパッチを作成していますが、 プロダクトのバージョンアップとパッチを当てたものの整合性を保つのは、 かなり大変な作業です。 こうした場面にも svk は威力を発揮することでしょう。 （執筆：大谷　弘喜）