エンジン一覧iエンジン リポジトリを実際に保管するバージョン管理システムのことです。fossil、git、hg、jj、lore のいずれかです。spicemine はそれらを置き換えるのではなくホストします。そのため、手元のツールは本物のエンジンと対話し、ここで独自の方言を覚える必要はありません。
リポジトリは何かに保管される必要があります。spicemine 自体が保管するのではなく、実際のエンジンをホストして、あとは邪魔をしません。どれが新しいかではなく、自分の働き方で選んでください。あとから変える場合は、移行ではなく新しいクローンになります。
どのエンジンにするか
Fossil
1ファイルで、必要なものすべて
向いているもの少人数で長く続くプロジェクト。課題、Wiki、メモを、作品と同じ1つのファイルに保てます。
注意点知っている人が少なく、git 前提のツール（CI、エディタのプラグイン、レビューサイト）は使えません。大きなバイナリはその1ファイルを膨らませます。
Git
他のすべてが前提とするもの
向いているもの誰とでも一緒に作業できること。あらゆるツール、サービス、協力者がすでに使っています。
注意点大きなバイナリは苦手で、専用の追加機能が必要です。コマンドは間違えやすいことで有名です。
Mercurial (hg)
git の素直な親戚
向いているものプログラマー以外もいるチームや、非常に大きなツリー。git と同じモデルを、落ち着いた一貫したコマンドで使えます。
注意点git より世界が小さく、対応するホスト、プラグイン、使い慣れた人が少なめです。
Jujutsu (jj)
git のデータに、取り消しボタン
向いているもの見せる前に作業を整え直すこと。積み重ねた変更、痛みのないリベース、すべてを取り消せる undo。それでいて、他の人にとっては普通の git リポジトリのままです。
注意点まだ若く、変化を続けています。このホストのタイムラインには jj 自身の change id ではなく、git のコミット id が表示されます。
Sub (a mirror of something hosted elsewhere)
他の場所のリポジトリを、ここに保つ
向いているもの他の場所を本拠地とするプロジェクトの、読めて clone できるコピーをここに保つこと。
注意点読み取り専用です。誰も push できず、内容は最後に更新した時点のものです。
Lore実験的
新しく、そしてそれが見える
向いているものゲーム、映像、音声、アート。大きなバイナリを重複排除したチャンクで保存し、作業コピーは開いたものだけを取得します。スタジオがふつうお金を払う商用サーバーに代わる、オープン（MIT）な選択肢です。
注意点1.0 前で、ここでは実験的です。形式は変わる可能性があり、ファイルロックは警告するだけで止めません。また lore には読み取り専用のアクセスがないため、読むだけの人はこれらのページか git ミラーから読みます。失えないものは別にコピーを残してください。
Fossil
1ファイルで、必要なものすべて
リポジトリ全体が1つの SQLite ファイルで、1つの小さなバイナリにバージョン管理、バグトラッカー、Wiki、フォーラム、そして独自の Web インターフェースが入っています。SQLite プロジェクト自体を運用するために書かれました。つまり、1つのコードベースを何十年も保守する人たちが、組み立てる必要のないものを求めて作ったものです。
向いている用途
少人数による長く続く仕事、そして同期すべき6つのサービスより、バックアップすべき1つのファイルを好む人に向いています。課題やメモを他社のデータベースではなく作品と一緒に置きたいなら、ここで唯一それを最初から実現しているエンジンです。
spicemine での扱い
完全にホストされています。spicemine がすべてのリクエストを自ら認可し、その後 fossil 自身の CGI に渡します。clone、sync、タイムラインのすべてが動作し、バックアップ対象はそのリポジトリファイルです。
状態
利用可能。clone、push、閲覧ができます。
Git
他のすべてが前提とするもの
業界の他の部分がその周りに築かれたエンジンです。ブランチが速く、ツールの豊富さは比類なく、そして噂どおりの箇所で扱いにくいものです。モデルは内容アドレス方式のスナップショットであり、だからこそリビジョンは差分ではなく状態を指します。
向いている用途
相互運用が必要なものすべてに向いています。すでに知っているチーム、2つ目のツールを覚えない貢献者がいるプロジェクト、git にしか存在しないエディタ拡張・CI・レビューツールを必要とする仕事などです。弱点は大きなバイナリファイルです。プログラマーのリポジトリより、写真家のアーカイブのほうが先に限界を迎えます。
spicemine での扱い
完全に、同一プロセス内でホストされています。spicemine が git の smart HTTP プロトコルを自ら提供します。HTTPS でトークンをパスワードとして clone / push でき、リポジトリページはオブジェクトストアから直接タイムラインと README を読み取ります。
状態
利用可能。clone、push、閲覧ができます。
Mercurial (hg)
git の素直な親戚
Mercurial は git と同じ分散モデルを持ちながら、積み上がったのではなく設計されたコマンド体系を備えています。作業を失う経路が少なく、同時に把握すべき概念も少なく、「怖くなくなる」バージョン管理として知られています。
向いている用途
全員がプログラマーではない混成チーム、そして大きなツリーに向いています。非常に大きなリポジトリを無理なく扱え、Meta や Mozilla が使い続けた理由の一部でもあります。ツールよりも作品のほうが大事だという人にとって、最初の選択として適しています。
spicemine での扱い
spicemine が起動しリバースプロキシするローカルの hgweb プロセス経由でホストされます。リクエストの認可は spicemine 自身が先に行います。clone、push、タイムライン、README のすべてが動作します。
状態
利用可能。clone、push、閲覧ができます。
Jujutsu (jj)
git のデータに、取り消しボタン
Jujutsu は、git のリポジトリをそのまま使いながら、別のコマンド体系を与えるものです。ステージング領域も detached HEAD もありません。作業コピー自体が1つのコミットです。すべての操作は記録され、`jj undo` で巻き戻せます。rebase も同様です。コミットが書き換えられても change は同一性を保つため、子孫の rebase を尋ねることなく自動で行えます。
向いている用途
作業を見せる前に組み替える人に向いています。積み重ねたブランチ、長いレビュー、何度も書き直すコミット列などです。通常の git リポジトリを読み書きするため、チームの他のメンバーがこれを選んだことを知る必要はありません。
spicemine での扱い
そのまま git リポジトリとしてホストされます。jj 自身のサーバーは存在しないため、`jj git clone` と `jj git push` は git と同じ HTTPS アドレスと同じトークンを使い、spicemine が各リクエストを自ら認可してから処理します。このページの履歴は、同じ保管領域の上に置かれたサーバー側の jj リポジトリが読み取っています。タイムラインに表示されるのは git のコミット ID です。clone、ミラー、git ユーザーのいずれもが一致して参照できる識別子だからです。change ID は当面、手元の側にあります。
状態
利用可能。clone、push、閲覧ができます。
Sub (a mirror of something hosted elsewhere)
他の場所のリポジトリを、ここに保つ
sub（サブ）とは、自分自身の履歴を持たないリポジトリです。アドレスを指定すると、このインスタンスがその場所の内容を、閲覧でき clone もできる形で保ちます。これは内側に向けたミラーです。リポジトリ自身のページにあるミラーが、このインスタンスの履歴を別のエンジンの形式で外に提供するのに対し、こちらは逆向きです。sub への push は拒否されます。次回の更新で上書きされてしまうためです。
向いている用途
本拠地が他の場所にあり、読み手がここにいるプロジェクトに向いています。控えを持っておきたい依存ライブラリ、git や jj のユーザーにも clone させたい fossil のプロジェクト、読み手を送り込みたくないサービス上のリポジトリなどです。
spicemine での扱い
上流が何を話していても、ローカルでは jj として保管されます（jj リポジトリを被せた git リポジトリです）。そのため1つの複製が、git クライアント、jj クライアント、タイムライン、バックアップのすべてに対応します。fossil の上流は fossil で clone し、fossil から git へのミラーと同じエクスポータで変換します。git または jj の上流は jj が取得します。構造上読み取り専用で、上流のアドレスは自身のページに明示されます。
状態
利用可能。clone、push、閲覧ができます。
Lore
新しく、そしてそれが見える
Epic Games によるオープンソース（MIT）のバージョン管理で、コードと大きなバイナリアセットが混在するプロジェクト、つまりゲームやエンターテインメントのために作られています。本人たちの言葉では「開発者とアーティストの両方のため」です。内容は重複排除されたチャンクとして保存されるため、数ギガバイトのファイルもテキスト1ページと同じくらい手軽に管理でき、作業コピーは開いたファイルだけを取得します。ステージ、コミット、ブランチ、差分は手元で動き、サーバーは記録の正本です。クライアントは他のエンジンが使う HTTP ではなく、gRPC（または QUIC）で lore サーバーと通信します。
向いている用途
ゲーム、映像、音楽、アートを作る小さな独立スタジオで、本来なら商用の集中型サーバーにお金を払うところ。そして一般に、ファイルが大きなバイナリで、テキスト向けのエンジンが軋み始めるような創作の仕事に向いています。設計はアクセス制御も重視しています。各リポジトリは独立したパーティションで、別の閲覧者を持つべきフォルダは、それ自体をリポジトリにして親にリンクする設計です。このリンクの仕組みは lore の 2026 年のロードマップにあり、まだ使えません。1.0 までは、作り直せる作品に選び、唯一のコピーには使わないでください。
spicemine での扱い
プロキシではなく、プロビジョニングです。spicemine が管理下の lore サーバーにリポジトリを作成し、clone 用のアドレスを渡します。lore クライアントはこれらのページではなく、そのサーバーと通信します。ここに表示されるタイムラインはサーバーから読み取ったもので、main ブランチのみを示します。0.42.0 からは、ファイルの一覧表示と閲覧、そしてファイルの追加(ドロップしたファイルや保存した会話)も、サーバーを通じて1つのリビジョンとして行えます。プロジェクトの他の部分は取得しません。
状態
実験的で、上流プロジェクトは 1.0 前です。リポジトリの作成、タイムライン、ファイルの閲覧とこれらのページからの追加は動作します。スペースに書き込める人は誰でも clone と push ができます。lore には読み取り専用のアクセスがないため、読むだけの人はこれらのページから読むか、プロジェクトの git ミラーを clone します（0.50.0）。失っても構わないもの以外は置かないでください。
このページの日本語は機械による下訳で、ネイティブによるレビューを待っています。読みにくい部分があれば、それはこの翻訳の問題です。