subversionにおける「リビジョン番号」「チェンジセット」に関するもやもやを整理してみた。
リビジョン番号は何を意味するのか?
- リビジョン番号「N」は、リポジトリ内のツリーの名前である
- N番目のコミットを終えた直後のリポジトリの姿である
レポジトリとリビジョンの関係は?
- リポジトリは、ツリーの配列である(the repository is an array of trees)
- リポジトリは、リビジョンの集合である
- ArchやBitkeeperはこれと逆で、レポジトリはパッチ(=チェンジセット)の集合である
チェンジセットとは何か?
- 変更の集合(a collection of changes)
- つまりパッチのこと
- 名前がついたパッチ
- 異なるツリーを比較して得られる導出物
「バグXを、リビジョン123で修正しました」の意味
厳密に言えば、「バグXを、"-r 122:123"のチェンジセットで修正した」ということである。よって、下記のsvn diffコマンドは同じであることが理解できる。
svn diff -c 123
svn diff -r 122:123
公式サイトのFAQ「Subversionにチェンジセットはあるのか?」
「チェンジセットとは、一意な名前をもった変更の集合である」。 「変更」には、ファイルコンテンツに対するテキスト的な編集や、ツリー構造に対する修正、また、メタデータに対するちょっとした調整も含まれる。 より一般的に言うならば、チェンジセットとは、あなたが参照できる名前をもったパッチのことだ。
Subversionは、バージョン付けされたツリーを第一階オブジェクトとして扱っており(リポジトリは、ツリーの配列だ)、チェンジセットは(近接のtreeと比較することで得られる)そこからの導出物だ。 ArchやBitkeeperなどのシステムでは、逆の理念の上に作られていて、これらのシステムはチェンジセットを第一階オブジェクトとして管理するように設計されている(リポジトリはパッチの集合体だ)。 ツリーは、パッチの集合を互いに組み合わせることで導出される。
どちらかの哲学が、他方よりも絶対的に素晴しい、というわけではない。 この議論は少なくとも30年は遡れる。 この2つの設計は、ソフトウェア開発のタイプによって、適していたり、そうでなかったりする。 ここでは、この議論を行うのは止めにして、その代わり、Subversionを使ってあなたは何が出来るのか、ということを説明しよう。
Subversionでは、グローバルリビジョン番号「N」は、リポジトリ内のツリーの名前である。 これはN番目のコミットを終えたリポジトリの姿だ。 またこれは暗黙的に一つのチェンジセットの名前にもなる。 もし、ツリーNとツリーN-1を比較すれば、コミットされたパッチそのものを引き出すことが可能だ。
これ故に、「リビジョンN」を、ただツリーとしてだけではなく、チェンジセットとして同様に捉えることも容易い。 もしあなたが要求管理システム(issue tracker)をバグ管理に使っているならば、特定のリビジョン番号を、バグを修正した特定のパッチを参照する為に用いることができる。 例えば、「この問題は、リビジョン9238で修正しました」という具合に。 他の人は 'svn log -r9283' と実行することで、そのバグを修正した完全なチェンジセットに関して読むことが出来るし、'svn diff -r9237:9238'とすれば、パッチそのものを見ることができる。 また、svn の merge コマンドもリビジョン番号を利用する。特定のチェンジセットを、あるブランチから他のブランチへマージするには、そのチェンジセット名を merge の引数へと与えればよい。 'svn merge -r9237:9238 branchURL'は9238番のチェンジセットをあなたの作業コピーへとマージすることになるだろう。
これは、チェンジセットを根源オブジェクトに据えて構築されたシステムみたいに複雑なことは出来ないけれども、でも、CVSよりは凄く便利だよね。
http://subversion.apache.org/faq.ja.html#changesets
これで長年のもやもやがすっきりしました。
カテゴリ:
Subversion