(http://arch.fifthvision.net/bin/view/Arx/MoreLinuxKernel)
Linux カーネルがバージョン管理システムに要求すること
"Would I prefer to use a tool that didn't have any restrictions on it
for kernel maintenance? Yes." -- Linus Torvalds
"If people in the open-source SCM community wake up and notice that the
current open-source SCM systems aren't cutting it, that's _good_."
-- Linus Torvalds
"Think of BitKeeper as a stepping stone, a temporary thing until a
better answer appears" -- Larry McVoy
ドキュメントバージョン 0.0.2
このドキュメントは Linux カーネル開発者に受け入れられるであろうバージョン管理
システムに対して要求される基本的なデザインについて述べています。そのような
システムに要求されるすべての機能を記述しようとしたものではありません。基本的な
構造についてのみ触れています。
分散可能なブランチ
1. 導入
分散可能なブランチの考え方は開発者に完全な、すべての機能を持ったリポジトリを
'メイン'のリポジトリから自分のシステムの上にコピーしてくることができるような
ものであり、完全なリポジトリの機能性を犠牲にすることなく、オフラインの状態や
別の開発者のグループと一緒に作業でき、その後その作業結果をメインのリポジトリ
や、別のリポジトリに書き戻すことができるようなものです。
この場合、'メイン'のリポジトリとは、単に与えられたプロジェクトのリーダによって
利用されるリポジトリというだけのことです。それは他のブランチにはないような
特別の機能や権限をもつわけではありません。それが'メイン'のリポジトリだと考えら
れるのは、単に社会的な意味でそうなのであって、技術的な意味ではありません。その
ため、メインリポジトリから複製したブランチは、複製元のリポジトリに'登録'する
必要はありません。つまり、ひとつのリポジトリはあらかじめ他のリポジトリに関する
情報なしに、そのリポジトリと相互にやりとりすることができます。
2. 振る舞い
ある別のリポジトリから作ったリポジトリは完全な複製です: 単に親リポジトリの現
在の状態なのではなく、親からのすべてのデータが、子供のリポジトリに含まれてい
なくてはなりません。
リポジトリを複製するとき、親に変更点をコミットによって書き戻すとき、あるいは
他のリポジトリと変更を共有するとき、ネットワーク上のリポジトリの場所に関して
どのような仮定もあってはなりません。リポジトリは同じマシン上にあるかも知れま
せんし、世界のどこか別の場所にあるまったく異なるマシンの上にあるかも知れませ
ん。
チェンジセット
1. 導入
チェンジセットはファイルのあつまりに対するひとまとまりの変更のことを言います。
チェンジセットは、変更か複数のファイルにまたがるとしても、リポジトリに対する
論理的なひとまとまりの変更として扱われます。典型的には開発者は手で、あるチェ
ンジセットに属するファイルの変更を'タグ'づけします。リポジトリの複数の局面で
作業している開発者は局面ごとにひとつのチェンジセットを作るかも知れません。
その場合、ひとつひとつのチェンジセットはある局面に関連する変更点からなります。
2. 振る舞い
2.1 タグ付け
与えられたチェンジセットの一部としてのどのようなファイルの変更にも、開発者は
簡単にタグづけすることができなくてはなりません。
ファイルに対する個別の変更は一つ以上のチェンジセットに属すことはできません。
2.2 バージョン化
チェンジセットは自分自身のローカルなバージョン番号か与えられ、チェックインご
とにその番号は増えていきます。
2.3 共有
email を介して、チェンジセットは交換することができなくてはなりません。
チェックイン
1. 導入
チェックインは与えられたリポジトリに対するローカルな変更からなります。これは
あるリポジトリを別のリポジトリにマージすることとは区別して考えなくてはなりま
せん。自分自身のリポジトリに対してローカルな変更をする開発者はチェックインを
ます。異なるリポジトリとの間で変更点を共有する開発者は、マージをします。
2. 振る舞い
チェンジセットの部分ではないファイルは個別に扱われます。チェックイン時には、
開発者はそれぞれのファイルにコメントを入れるかも知れません。これはチェックイン
全体に対して唯一のコメントをいれるようなバージョン管理システムとは違います。
ローカルリポジトリにひとつのチェンジセットをチェックインすることができなくては
なりませんし、そのようなチェンジセットは独立した単位として扱うことができなくて
はなりません。それはちょうど普通のファイルがそうであるような意味で、です。
チェックイン時には、開発者はチェンジセット全体にたいして一つのコメントをつけま
す。
マージ
1. 導入
マージはふたつ以上のリポジトリの間の変更点を送ったり受け取ったりすることから
なります。
2. 振る舞い
2.1 ローカル作業の保存
リモートリポジトリに対して行った変更点にマッチするようなローカルリポジトリを
update することができなくてはなりませんが、その一方で同時に、ローカルリポジトリ
にした変更点は保存されなくてはなりません。もし同じファイルのどこかがローカルと
リモートのリポジトリの両方で変更されたことによって衝突がおきた場合、衝突解消の
ためのツールはローカル開発者に対して自動的に起動されなくてはなりません(以下
を参照)。
チェックインが何かの理由で中断された場合、クリーンアップ処理がツリーに対して
実行され、矛盾のない、正常な状態に復帰しなくてはなりません。
2.2 履歴の保存
チェックインタグとリビジョン番号は与えられたリポジトリに対してローカルになりま
す。リポジトリ間で重複が起こるかも知れないので、このような履歴の詳細はチェック
イン時にはリモートリポジトリ中でユニークになるように再マップされなくてはなりま
せんが、それでもその起源を特定することができなくてはなりません。
二つのリポジトリ間のマージは現在のチェンジセットの状態をマージすることだけでは
なく、それらの完全な履歴、それらがかかわってきたすべてのバージョンとファイルを
含んでいなくてはなりません。
もし与えられたパッチのための履歴情報が利用できないのなら、システムはそのパッチ
をローカルな編集としてあつかい、それをチェンジセットにすべきです。
この実装は他のどのリポジトリが報告する時刻が正確であることに依存してはなりません。
3. グラフ構造
[この章は Petr Baudis からの email を部分的に引用しています]
上記の振る舞いのいくつかを図であらわすために、以下の DAG(有向グラフ)を見てくだ
さい。このグラフはそれぞれのリポジトリから見たときに異なって見えるかも知れません。
(図ではチェンジセットの番号を表示しています)。架空のLinus のブランチを考え、
それが以下のようだったとします:
linus 1.1 -> 1.2 -> 1.3 -----> 1.4 -> 1.5 -----> 1.6 -----> 1.7
\ / \ /
alan \-> 1.2.1.1 --/---\-> 1.2.1.2 -> 1.2.1.3 --/
しかし Alan のブランチではそれは以下のように見えます:
linus 1.1 -> 1.2 -> 1.2.1.1 -> 1.2.1.2 -> 1.2.1.3 -> 1.2.1.4 -> 1.2.1.5
\ / \ /
alan \-> 1.3 ------/---\-----> 1.4 -----> 1.5 ------/
ファイルごとのリビジョンではなく、チェンジセットを記録する仮想的なブランチ
はマージする時に親ディレクトリ中に作られます。この時点でマージされたチェンジ
セットはそのブランチに適切な新しい番号を受け取ります。しかし、そのブランチは
仮想的なものなので、リポジトリ中にはまだ開発のひとつのラインしかありません。
適用された順序でチェンジセットを眺めるためには、リビジョン番号によってソート
されてはならず、マージの時刻によってソートされなくてはなりません。それで上の
図に従うと、パッチが適用された順序は、Linusから見たときには:
1.1 1.2 1.3 1.2.1.1 1.4 1.5 1.6 1.2.1.2 1.2.1.3 1.7
となります。
分散環境下でのファイル名の変更
1. 導入
これは、開発者にファイルやディレクトリの名称変更、作成、削除を認めることと、すべての
リポジトリ操作がこれを正しく認識し扱うことができるようにすることです。
2. 振る舞い
2.1 ローカル
ファイルとディレクトリのローカルでの名前変更はチェンジセットタグを含むすべての履歴情報
を保存しなくてはなりません。
2.2 分散可能性
一般的な場合、一つのローカルリポジトリはリモートリポジトリと名前の変更のマージをしよう
とすることがあります。このような場合、リモートリポジトリはチェンジセットタグを含むすべ
ての履歴情報と共に名前の変更を受け取ります。
2.2.1 衝突
ひとつのリモートリポジトリまたはそれぞれのリモートリポジトリから複製された
任意の数のリポジトリはひとつのファイルの名前を他の任意の名前に変更しようと
するかもしれず、その場合、その変更はひとつのリモートリポジトリ、またはお互いに
マージしようとするかも知れません。
一つのリモートリポジトリまたはお互いから複製された任意の数のリポジトリは
ファイルAを何か別の名前に変更し、それから他のファイルが以前ファイルAで使われて
いた名前に変更されたり、以前Aで利用されていた名前で新しくファイルが作られたり
するかも知れません: それからそれらの変更が一つのリモートリポジトリにマージされ
たり、お互いにマージされたりするかも知れません。
一つのリモートリポジトリやお互いから複製された任意の数のリポジトリは同じ名前
のファイルを作ろうとしたり、その変更をリモートリポジトリ、またはお互いに書き戻
しマージしたりするかも知れません。あるいは、任意のファイルが同じ名前に変更され
たり、どこか別の場所でつくられたファイルが作成されてから削除されるかも知れませ
ん。あるいはローカルにちょうど削除されるか移動されたディレクトリ中にファイルが
作られたりするかも知れません。などなど。私はこれはラリー(Larry McVoy)以外の人は
誰も考えなかったような非常にまれでやっかいな場合の一つだと信じています。
グラフィカルな 2 ウェイと 3 ウェイマージツール
1. 導入
マージツールはファイルをマージする時に衝突を解決するのに使うツールです。
tkdiff を参照してください。( http://www.accurev.com/free/tkdiff/ )
2. 振る舞い
マージツールは衝突の領域を正確に特定し、ユーザが衝突を解消しパッチを適用できる
ようにファイルを簡単に編集できるようにするものです。
マージツールは、ファイル全体と同時に、パッチも扱うことができなくてはなりません。
典型的な利用方法は、リモートリポジトリからのローカルツリーへの最近の変更のすべて
をもってくるようなものです。それからマージツールを使ってリモートリポジトリと
ローカルでした変更の間のすべての衝突を解消し、ローカルファイルをタグ付けして
チェンジセットを作り、共有するための diff を生成します。
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
このドキュメントは Zack Brown によってコピーライトされており、GNU の
General Public License のバージョン 2.0 の下でリリースされます。
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *