質問と批評

このページはfossilに対して挙げられた質問と批評および、それらに対する作者からの回答のコレクションです。

付記：この他よくある質問も参照してください。

Fossilは車輪の再発明のように見える。なぜ、自分用の分散VCSを作ったのですか？

私が fossil を書いたのは、私の要求に合う分散VCSが無かったからです。もし他の分散VCSがあなたの要求に合致するなら、fossil ではなくそちらを利用するのがいいでしょう。しかしながら、私に合うものはなかったのです。そのため、私には fossil が必要だったのです。

fossil に有り、他では見た事の無い機能は次の通りです。

統合されたwiki

統合されたバグトラッキング

変更されないアーティファクト

chroot jail環境でも利用が可能な、スタンドアローンな実行ファイル

単純でよく定義された耐性の強いファイルフォーマット

統合されたwebインターフェース

Tracよりもfossilを使うべきなのはどうしてですか？

Fossil は分散化されています。オフラインでチケット、Wiki、コードを閲覧・編集して、後から変更を同期できるのです。Trac の場合、サーバに接続していても、チケットとWikiを閲覧・編集できるだけです。

Fossil は軽量で、単一のファイルに全てを含んでいます。そのため、リソースの少ないマシンにも簡単にインストールできます。また、Fossil は管理者(訳注：の権限)を必要としません。

Fossil はWikiとチケットのリポジトリをコードのバージョン管理と統合しています。そのため、追加のインストール作業を必要としません。 Fossil は全てを含んだ簡易なソリューションなのです。

素晴しいコンセプトです。実際の仕事でも使われているんですか？

Fossil は自己ホスティングしています。事実、おそらくこのページは動作中のfossilのインスタンスからWebブラウザへ送信されているでしょう。(訳注：日本語版は通常のWebサーバ上にあります) http://www.fossil-scm.org/ をホストしているのと同一のマシン上で Linode 720に加えて24もの小さなプロジェクトのfossilリポジトリがホストされています。また、SQLiteのドキュメントもここのfossilリポジトリにあります。他のプロジェクトでもfossilに合うものがあるでしょう。しかし、fossilはまだ git や mercurial のような大量のユーザベースで使われたことはありません。

Fossil はLinksysのルータが出す管理スクリーンみたいに、バグトラッカーのように見えるのですが？

私はソフトウェア作成に、形状は機能に付随するという実践的なアプローチを取っています。私にとっては見栄えよりも、信頼性のある、速く、効率的な、高耐久の、シンプルなDVCSであることの方が重要なのです。

そのため、もしあなたが信頼性、パフォーマンス、メンテナンス性に深刻な影響を与えずに見栄えを改善するパッチを用意してくださるなら、喜んで受理するつもりです。Fossilは自分でホスティングしていますので、メインの fossilリポジトリにコードをコミットするためのパスワードはメールで要求してください。

バグトラッキングデータベースをバージョン管理されたファイルへ読み書きするアプリケーションを分離して、そのファイルを残りのリポジトリへ書き込むようにすると、より便利になるように思うのですが？

Fossil はバグ情報をリポジトリ内のファイルに格納します。しかし、fossil はバグ情報をソースツリー上のファイルとしては扱いません。ご指摘のバグトラッキングアプローチは次の3つの理由により適さないと考えます。

Fossil でのチェックインは不変です。そのため、チケットがチェックインの一部であると、新しいバグが発見された時などに新規のチケットを追加できなくなってしまいます。

適当なサイズと複雑さを持つプロジェクトの場合、何千何万ものチケットが生成されます。これらによってソースツリーをぐちゃぐちゃにしたくありません。

チケットの管理にはWebインターフェイスを使い、コードのチェックインとは別の認証情報を利用したいのです。つまり、チケットの作成と編集を、fossilがインストールされていたり、チェックイン権限を持つ開発者であったりといった点によって制限されたくないのです。インターネットを通りがかっただけの人でもチケットの作成ができるべきなのです。

これらの点についてはバグトラッキングドキュメントの最初の段落にも書いてあります。

Fossil とは、plan9 の追加専用バージョン管理ファイルシステムの名前なのですが？

私はそのことを知りませんでした。おそらく、その命名も私と同じように「不変のアーティファクトで構成されるリポジトリは、長く続くプロジェクトの歴史を表す素晴しい化石である」という考えからなのでしょう。

リポジトリをSQLiteデータベースのように、Blob(Binary Large OBject)として保存するのは危険な気がするのですが？

SQLiteをリポジトリの保存に利用しようと思ったのは、他のアプローチに比べて安定性と安全性が高かったことに加え、SQLiteがトランザクションをサポートしていたためです。なお、Fossilでは情報の欠落が起こらないように、内部の自己チェックを実装しています。

私はwikiやバグトラッキングをVCSに含めることの効果が疑わしいと思います。それはTracのようにフル機能なソフトウェアより機能で劣り、SubversionやBazaarのようなVCSよりも大きなサイズになるでしょう。

私はTracがfossilに欠けている機能がより多く含まれていることは疑いません。しかしながら、重要なのはその点ではないのです。Fossilには私にとってTracに欠けているいくつかの重要な機能(特に非接続状態での作業)が含まれています。

サイズの増大については、Fossil 単体で全てを含んでいることを考慮して頂きたい。 Fossilを利用する場合、他にどのようなパッケージ(diff、patch、merge、cvs、svn、 rcs、git、python、perl、tcl、apache、sqliteなどなど)も不要なのです。 Fossil はchroot閉鎖環境であっても、それ単独で動作します。そして、全部を含んでいても 1MB弱くらいのサイズなのです。これらを考慮すると、fossilはサイズが大きいとは言えないでしょう。