【3】パフォーマンスとスケーラビリティ
分散バージョン管理システムでは各開発者が持つローカルリポジトリが履歴情報を管理するので、変更履歴の参照やファイルの取り出しのためにサーバへ接続する必要がありません。また、作業はローカルのリポジトリへコミットを行い、ある程度まとまったところで中央リポジトリへ反映できます。サーバへ接続する頻度が減るためパフォーマンスは上がります。
また、上記の図4で紹介したような階層的なリポジトリ構成を取っておけば、大規模なシステム開発でも各グループのリポジトリのアクセスへ分散できるので、アクセスが集中して遅くなるという問題が発生しにくくなります。
【4】オフラインによる開発
各開発者のローカルリポジトリで作業しますので、中央リポジトリに接続しなくてもバージョン管理ができます。出張やネットワーク障害などで中央リポジトリに接続できなくなった場合でも開発を継続できます。
ただし、最近のシステム開発では情報漏えいを懸念してセキュリティが厳しくなってきているため、利用には注意が必要です。
【5】障害に強い
各開発者が持つローカルリポジトリに完全な履歴が保存されているので、中央リポジトリのサーバが故障しデータが消えた場合でも復旧が容易です。中央リポジトリが故障し、その復旧に時間がかかる場合、中央リポジトリが復旧するまでほかのリポジトリをマスターとして利用することも可能です。
【6】オープンソースの改編物の公開に最適
あるオープンソースを改編して作成したソフトウェアを公開するときに、ローカルリポジトリを「オレオレブランチ」として簡単に公開できます。本家のリポジトリの内容が変更されても簡単に変更に追従できます。
ローカルリポジトリを公開しておけば、本家の開発者がその変更を取り込みたい場合、ローカルリポジトリの変更をマージするだけで取り込むことができます。
【7】SVNを集中リポジトリとして利用可能
すべての分散バージョン管理システムがサポートしているわけではありませんが、分散バージョン管理システムの多くは、デファクトスタンダードであるSVNを中央リポジトリに利用し、ローカルの管理は分散バージョン管理システムで管理できます。過去の遺産がSVNに蓄積されていて、容易に分散バージョン管理システムに乗り換えられない場合でも、部分的に利用できます（図5）。
このような構成にすれば、すでに中央リポジトリとしてSVNを利用しているプロジェクトでも、バージョン管理サーバを移行することなく分散バージョン管理システムを利用できますし、分散バージョン管理システムが使いづらいと感じてもクライアントをSVNに切り替えれば従来どおりの開発に戻れます。
また、分散バージョン管理システムを使いたい開発者だけ分散バージョン管理システムを利用し、SVNに慣れた開発者はSVNで開発するといった運用も可能です。
コラム 「分散型特有ではないが、こんな5つの機能も」
分散バージョン管理特有の機能ではありませんが、Mercurial、Bazaar、Gitなどの分散バージョン管理ツールはSVNより後発だけあり、次のような便利な機能を提供しています。
【1】簡単なリポジトリ作成
SVNの場合、リポジトリを作成して、管理したいリソースをインポートし、さらにインポートしたリソースを中央リポジトリからチェックアウトする必要があります。分散バージョン管理ツールでは、リソースあるディレクトリでバージョン管理を行うための初期化を行えば、すぐに成果物の構成を管理できます。
【2】高度なマージサポート
作業用のブランチ上での変更を、プッシュなどの簡単な操作でブランチ元のブランチへマージできます。また、ブランチを作成した後でブランチ元のコードに変更があった場合、ブランチ元の変更を取り込み、ブランチした位置をずらずRebase機能が提供されいます（図6）。Rebase機能により、ブランチ上の作業に直接関係ないマージによるログの増加を防ぐことができます。
【3】高度なパッチ管理
分散バージョン管理システムでは、パッチの管理をサポートする機能があります。GitやMercurialにはパッチに名前を付けて管理し、自由にパッチの取り外しをできるようにする機能があります。
【4】リポジトリの共通が簡単
共有ファイルサーバ上でリポジトリを共有するだけで、簡単にリポジトリを共有できます。さらに、MercurialとBazaarはリポジトリ共有用のサーバをコマンド1つで起動できます。GitとMercurialはHTTPプロトコルで簡単に公開し、リポジトリ情報をWebブラウザで閲覧できます。
【5】Bisect機能
不具合が混入したリビジョンの特定を支援する機能です。Bisect機能を利用すると、テストにパスしたリビジョンとテストに失敗したリビジョンを2分探索を行いながら不具合が発生したリビジョンが特定できます。探索を行うためのリビジョンのコードへ自動的に切り替えてくれます。
さて、分散バージョン管理のメリットは理解できたでしょうか。上記の特徴のいくつかは、使い方や運用を工夫すればSVNを利用した場合でも同様のことは可能です。分散バージョン管理システムでは最初から分散開発をすることを想定しているため、これらの機能をスムーズに使いこなすことができます。
分散型はデメリットも7つ……
さて、ここまでで分散バージョン管理システムを使えばいかにもバラ色の人生が待っているように思われた方もいらっしゃると思います。将来的には解決される可能性もありますが、現在のところ下記のようなデメリットもあります。
【1】管理が煩雑に
リポジトリごとに独立したリビジョン番号を付与するため、リビジョンを指定しただけでは誰のどの変更か分かりません。すべてのリビジョンで共通に使えるリビジョンとしてハッシュを利用しますが、リビジョンの指定が分かりにくいという欠点があります。
また、自分のローカルリポジトリへコミットしてから、変更をマスターリポジトリへプッシュする必要があるので、SVNに比べると煩雑な手続きとなります。
【2】ロックができない
SVNではロック機能があるので、ほかの開発者による編集を防ぐことができます。ExcelやWordのドキュメントなどバイナリ形式のファイルを編集する際にこの機能は便利です。
一方で、分散バージョン管理システムではロック機能が使えません。ExcelやWordで記述された設計書などの管理には不向きです。
【3】細かいアクセス制御ができない
SVNはディレクトリごとに、どのユーザーにread/writeを許可するか細かいアクセス制御が可能です。分散バージョン管理ツールでは、基本的にリポジトリ単位のアクセス制御しかできません。
最もアクセス制御で進んでいるMercurialでもディレクトリにアクセス可能/不可能を設定できるだけで、read権限、write権限と細かい制御はできません。
【4】リポジトリ単位しか作業セットを取得できない
ローカルのリポジトリはリポジトリの完全な履歴を保持するため、中央リポジトリを利用する場合、中央リポジトリ上の任意のモジュールだけ取り出しての開発はできません。完全なリポジトリのコピーが必要となってしまいます。これに対して、SVNでは任意のディレクトリをチェックアウトして編集できます。
【5】Windows用のツールが成熟していない
SVN用のWindowsクライアントであるTortoiseSVNを利用すると、リビジョン間のExcelやWord文書の差分を表示したり、リビジョンの関係をグラフ化して見ることができます。分散バージョン管理で利用できるWindows用のクライアントも提供されていますが、SVNほど高機能ではありません。
【6】一般開発者向けのノウハウが十分に蓄積されていない
オープンソースの開発では実績も十分でてきており、Emacs用のスクリプトの提供をはじめノウハウもたまってきました。しかしながら一般の開発者向けにはまだノウハウがたまっていないように思えます。
分散バージョン管理システムによっては、WindowsとUNIX環境で併用すると文字化けしたり、GUIツールもないことはありませんがまだ開発途上といった感じです。
【7】利用経験があるエンジニアを集めにくい
分散バージョン管理システムを利用したことがある開発者はあなたの周りにいますか？ ほとんどの人が利用したことはないと思います。利用経験者が少ないので、教育コストや運用ルールの確立にコストが掛かるでしょう。
分散バージョン管理ツールには、GitやMercurial、Bazaar、SVK、Monotoneなどさまざまなものがあります。次ページからは、最近採用実績が増えており、（筆者の独断で）メジャーになるだろうと思われるGit、Mercurial、Bazaarを紹介します（筆者の独断が含まれているので、違うと思われる方はぜひ、＠IT会議室やはてなブックマークなどでコメントいただければと思います）。
Copyright © ITmedia, Inc. All Rights Reserved.