バージョン管理システムにGitやMercurialなどの比較的新しい分散型バージョン管理システムを採用する事例が増えている。もともとOSSプロジェクトで採用するバージョン管理システムは中央集権型のCVSが多かった。しかしCVSは厄介な面もあり、こうした問題を解決した同じく中央集権型のSubversionがCVSの次期候補として注目されていた。
- CVSからGitへ、Fedora 13以降
- 止まらないGit人気、JRubyも移行 - 対抗馬はMercurial
- Git人気が止まらない、今度はGnome
- Gitバージョン管理システム採用拡大、Perl 5も移行
- 7つのバージョン管理システムを知る
しかし現在のところ、バージョン管理システムは分散型のMercurialとGitに注目が集まっており、実際にOSSプロジェクトが従来のバージョン管理システムからこれら分散型のバージョン管理システムへの移行を進めている。これまでSubversionを使ってきた開発者がGitを使い始め、その利点に驚いたというストーリーがWhy I'm leaving Subversion for Git - Javalobbyで紹介されている。中央集権型のどういった点が使いにくく、分散型のどういった点が扱いやすかったかという点がわかりやすくまとまっている。
紹介されているGitが便利なポイント |
---|
使うにあたって必ずしもリモートリポジトリを持っている必要がない。ローカルリポジトリで作業を開始し、それに対してコミットを実施できる。リモートにコミットする必要があるSubversionがとても重く感じられ、Gitはとても素早く感じられる。 |
変更した内容はまとめてほかのリポジトリに適用したり、ほかのリポジトリの変更内容をマージすることができる。マージがちゃんと実施されるか懸念していたが正確にうまく機能している。 |
Gitにはコミットアクセスという概念がない。従来の方式ではメインとなるブランチがあり、そのコピーを各々の開発者が持つことになる。メインブランチへのアクセスは特定の人物に制限されており、権限を持たない開発者はバグシステムにパッチを登録するなりメールでパッチを提供するなどして取り込んでもらう必要がある。コピーされたリポジトリという方式は一貫性を保つのが大変。Gitではこうした問題がない。それぞれが自分のリポジトリを持っており、リポジトリごとにマージが実施される。 |
なお、Subversionを使い続けているOSSプロジェクトもある。移行の手間もそれ相応にものになるため、運用がうまくいっており、CVSやSubversionを使っていて特に問題が発生していない大規模プロジェクトではそのまま従来のバージョン管理システムを使い続けているケースもある。