日々の破片

_ ソフトウェアのコペ転

バージョン管理の歴史を読んでいて、そうそうSCCSと違ってRCSは最新持ちなんだよなぁとか思い出して、それからふと愕然とする。

もし、今、山奥で50年間くらいこもっていたプログラマ仙人(つまりgithubはもちろんのことrcsもsccsも知らない)が、ソース管理ツールを作るとしたら、どう作るだろうか？

最初のコミットはソースそのものの保存となる。

次のコミットは元のソースと最新のソースの差分と……どちらの原型を保存するか？

もし、そこで次のコミットのことを考えたら、そりゃ最新を保存するだろう。

そうすれば、次にコミットも最新のソースとレポジトリから取り出したソースの差分の保存で済む。

つまり、一番頻繁に行われるのは、常に最新の取得と最新のコミットなのだから、原型としてレポジトリに保持するのは最新の内容が低コストだ。ソースコード管理という観点からは、そのほうが自然な発想に思う。

が、最初の実装であるSCCSは、オリジナルを保存することに決めた。

何しろ最初の実装なのだから、ユースケースを想像しなければ、オリジナルと差分の積み重ねという考え方のほうが自然だったのかも知れない。それとも、最初に作ったものが正で、その後のはすべて派生に過ぎない（でも、そうだったら差分の積み重ねという発想とはならないだろう）と考えたのかな。

で、The Source Code Control Systemを読むわけだが、いきなり、

COMPUTER programs are always changing

と始まる。で最重要項目としてまっさきに挙げられているのがディスクスペースの話なので、1975年という当時のコンピュータのディスク容量に思いをはせずにはいられなくなるわけだ。で、読んでいると、これはやはり複数バージョンの管理の観点であって、プログラム開発の話ではないことに気付く。そこからオリジナルの保持以外はまったく念頭には無いことがうかがえる。

というところで、RCSがいかにUNIXという思想を反映しているか、ということにもなるのだろう（しかも、どう考えても実装がKISSだ。SCCSだとコミットする都度、レポジトリの該当系列の最新のソースを復元する必要があるわけだし、そこが逆にRCSだとトランク以外の扱いがなんか妙に厄介だったような記憶があるけど忘れた）。プログラムを開発するためのシステムであることが前提なので、一番重要なのは常に最新のコミット（よりもワーキングファイル）だ。