知らぬ間にx264のバージョン管理システムが、SVNからgit（ぎっと）なるものに移行していたらしい。Timeline - x264 - Trac は、2008/02/03 の rev745 で途絶えているので[URI]、それ以降。gitはなかなかのやっかいものであるらしく、巡回先では褒めてるところが無い。なんだこれわと思って調べてみた。
ちなみにx264はVLCプロジェクト [URI] の一部なので、VLCも移行した模様。
Linuxカーネルのソースコード管理専用にLinus Torvaldsが開発したバージョン管理システム。
Linuxカーネルは、バージョン2.4まではLinus Torvaldsが手動で管理していたが、世界中の開発者から提供されるパッチの反映作業が膨大になったため、バージョン2.4から、BitMover社が開発するBitKeeperというプロプライエタリなバージョン管理システムが採用された。しかし、その後Linuxカーネル開発者の一人がライセンスに違反して、BitKeeperのリバースエンジニアリングを開始したとの報告があったため、Bit Mover社の権利を侵害しないように、Linus TorvaldsによってBitKeeperの使用を中止する決断がなされた。
gitはこのような事情の下にBitKeeperの代替手段として開発されたため、操作性や汎用性が犠牲となっており、汎用的なソースコード管理に使われることは意図していない。
Git はマージした履歴を正確に管理し、複数のブランチ間で複雑にマージが行われた場合でも、どのブランチに何が含まれていて、何が含まれていないのかを正確に教えてくれます。また、並行開発の履歴をビジュアルに表示する強力なＧＵＩツールも持っています。
これらは、１つのコミットが複数の親を持てるという内部デザインに起因しているのですが、これまでのＳＣＭには無かった革新的な機能です。
集中リポジトリの場合、コミッターとそれ以外の人との階級差別が発生しますが、分散ＳＣＭではこの階級差別がありません。だれもが自分専用のリポジトリエリアを用意することができ、好きなだけブランチを作成できます。そして、ネットワーク的に離れている別のブランチの変更を簡単にマージすることができます。
Linuxカーネルのように100MB超規模のソースでも軽快に動作します。
一般的に分散ＳＣＭはその性質上、何の操作をするにもソースツリーの全捜査が行われます。その為、ソース規模が大きくなると、パフォーマンスが急激に落ちます。
ところが、git の場合、どういう仕組みなのかは知りませんが、これまでの分散ＳＣＭにはない劇的なスピードで動作します。
ＣＶＳなどのＳＣＭと異なり、一度行った変更の取り消しが簡単に行えます。
コミットしたあとに修正ミスに気がついた場合、前回のコミットを取り消してコミットしなおすことができます。
gitは、Linuxのソースコード管理の為に、Linus Torvaldsが作った「分散型ソースコード管理システム」。最重要項目は使う側から見た分かりやすさではなく、過去のソースをいつでも取り戻せる事。誰でも好き勝手に開発できる事。文書に例えると、大勢で一枚のドキュメントを編集してんだけど、参加者全員が、いつでも好き勝手に編集できて、全員の、全てのアンドゥを、いつでも取り戻せる。みたいなものだと思う。
たぶんCVS/SVNのような、細かいバージョン管理は眼中になく、「開発の区切り」は「リリース」や「tarball」にお任せで、ソレ以外の変更は全て、流動的な「推敲の途中」というスタンスのようだ。
実際、Linus Torvaldsは、CVS/SVNなんか駄目だ！と言っているらしい。→ satolog: リーナス・トーバルズ「Subversion ほど無意味なプロジェクトはない」によると、ブランチ速度よりマージ速度の方が重要だそうで。ソースコードが100MB規模ではそうだろう。おそらく、ブランチ開発などローカルで勝手にやれば良い。マージも勝手にやれば良い。駄目なら勝手に直せば良い。「リリース」だけは面倒みてやる（そういう言い方は誰もしてないが）。ということではないか。
また、ソースコード持ってくだけで開発に手を出さない一般人（オレとか）は、「リリース」や「tarball」使っててくれ、というのは（そういう言い方は誰もしてないが）、理解できる話だ。
それはそれとして、VLCプロジェクト（x264含む）のどこに、gitに移行する必要があったのか？が気になる。意味もわからぬまま登録し続けているVLC, x264のメーリングリストには、かつての「コミッター」がgitに苦労している例が散見される（技術用語は相変わらず分からないが、英語は読めない事も無い）。その苦労を圧してgitに移行するからには、なんか理由があるだろう。
VLC自体は、最も多くのプラットフォームをサポートするGUIプレイヤの一つだ。Linux、Mac OS X、Win、BeOS、BSD、携帯情報端末、Solaris、VLCポータブルなどで、Apple/MSその他いかなるプロプライエタリ製品よりも、幅広い動画フォーマットを再生できる。Linux/Winでは、Mozilla/Firefox/ActiveXのプラグインも出している。初期のMiro（Democracy当時）のMac OSX版は、動画再生にVLCを内蔵していた（現在はPerianベースのQuickTime）。Songbirdも、動画再生にVLCを内蔵している。こうした幅広いニーズを中央集権型の開発体制で続けるには、中央に莫大な設備投資がかかる。
はたまた、VLCはエンコーダでもある。事実上使い物にならないが、一応、GUIでコンテナ変換や映/音エンコードもできる。のみならず、ストリーミング・サーバーでもある。使い物になるかどうかは知る由もないが、かつてのVLS（Video LAN Server）の機能を取り込んでいる。もとよりVLC（Video LAN Client）でもあるので、妥当なハード、ソフトと組ませれば、理論上は無反応機 [例：コピー制限の記載が無い地デジの録画PC]のベースにもなりうる。
他方、オープンソースにはGStreamerというものも存在する。これはffmpeg/MPlayer/VLCのような単独アプリケーションとは異なり、QuickTime/DirectShowなどの「マルチメディア・フレームワーク」に相当するものだ。現在は動画再生に VLC を使っている Songbird だが、ゆくゆくは主要3プラットフォームとも、こちらに乗り換える意向を明らかにしている。変更が頻繁なので実用にはまだちょっとというカンジのようだが、逆に言えば、それだけ開発が盛んという事でもあるわけで、実際、LinuxにおけるiTunesに相当するAmarokは、GStreamerをベースにしている。となりゃそっちに興味を持つ開発者も多いのだろう。
増大する一方の応用範囲をカバーする上でも、「フレームワーク」に流れる開発者をかき集める上でも、「マルチメディア・プラットフォームのモノリシック・カーネル」みたいな方向性はアリかもしんない。