Sapling は、世界最大のリポジトリにスケーリングしながら、使いやすさを重視しています。
Facebookが発表 ソースコード管理システムのブログ投稿を通じて 苗木 会社の内部プロジェクトの開発に使用されます。 システム バージョン管理インターフェースを提供することを目的としています 数千万のファイル、コミット、およびブランチにまたがる非常に大規模なリポジトリに拡張できます。
このシステムの主なアイデアは、リポジトリ ストレージを提供するサーバーの特別な部分と対話することによって、 すべての操作はファイル数に基づいてスケーリングされます 開発者が作業しているコードで実際に使用され、リポジトリ全体の合計サイズには依存しません。
たとえば、開発者が非常に大きなリポジトリからコードのごく一部のみを使用すると、リポジトリ全体ではなく、このごく一部のみがシステムに転送されます。 作業ディレクトリは、リポジトリ ファイルがアクセスされると動的に埋められます。これにより、一方ではコードの一部の作業を大幅に高速化できますが、他方では、アクセスすると速度が低下します。初めて新しいファイルにアクセスし、一定のネットワーク アクセスが必要です (別途提供され、オフライン コミット準備モード)。
アダプティブ データ ローディングに加えて、 Sapling は、変更履歴を使用して情報の負荷を軽減することを目的とした最適化も実装します。 (たとえば、Linux カーネルのリポジトリ内のデータの 3/4 は変更履歴です)。
変更履歴を効果的に操作するために、それに関連付けられたデータはセグメント化されたビューに保存されます。これにより、コミット グラフの個別の部分をサーバーからダウンロードできます。 クライアントは、いくつかの確認の関係に関する情報をサーバーに要求し、グラフの必要な部分のみをダウンロードできます。
このプロジェクトは過去 10 年間開発されてきました また、マスター ブランチを使用して非常に大きなモノリシック リポジトリにアクセスする際の問題を解決するために作成されました。ここでは、「マージ」の代わりに「リベース」操作を使用する慣行が行われていました。
当時、そのようなリポジトリを操作するためのオープンなソリューションはありませんでした。Facebook のエンジニアは、より複雑な依存関係管理につながるプロジェクトを小さなリポジトリに分割するのではなく、会社のニーズを満たす新しいバージョン管理システムを作成することを決定しました (かつて、同様の問題を解決するために、Microsoft は GVFS レイヤーを作成しました)。
当初、Facebook は Mercurial システムを使用していました。 Sapling プロジェクトは当初、Mercurial への追加として開発されました。 時間が経つにつれて、システムは独立したプロジェクトになりました 独自のプロトコル、ストレージ形式、およびアルゴリズムを備えており、Git リポジトリとやり取りする機能も拡張されています。
作業用、 コマンド ライン ユーティリティ「sl」が提案されています。 これは、Git と Mercurial に精通している開発者になじみのある典型的な概念、ワークフロー、およびインターフェイスを実装しています。 Sapling の用語とコマンドは、Git とは少し異なり、Mercurial に近いものです。
追加機能の中でも 苗木のハイライト 「スマート登録」のサポート (smartlog)、リポジトリのステータスを視覚的に評価できます。 最も重要な情報を強調表示し、マイナーな詳細を除外します。 たとえば、引数なしで sl ユーティリティを実行すると、独自のローカル変更のみが表示され (外部のものは折りたたまれます)、外部ブランチのステータス、変更されたファイル、コミットの新しいバージョンが表示されます。 さらに、スマート ログ、変更ツリー、およびコミットをすばやくナビゲートするためのインタラクティブな Web インターフェイスが提供されます。
Sapling のもう XNUMX つの注目すべき改善点は、 エラーを修正して分析し、以前の状態に戻すプロセスがはるかに簡単になります。 たとえば、コマンド「sl undo」、「sl redo」、「sl uncommit」、および「sl unmend」は、多くの操作を元に戻すために提案され、「sl hide」および「sl unhide」は、コミットを一時的に非表示にしてインタラクティブなナビゲーションを行うために提案されています。 Sapling はコミット スタックの概念もサポートしています。これにより、複雑な機能をより小さく、より理解しやすい一連の変更 (基本的なフレームワークから最終的な機能まで) に分解することで、レビューを段階的に整理できます。
別々に、 サーバー部分は、リポジトリを使用した効果的なリモート作業のために開発されました 仮想ファイル システムは、リポジトリの一部のローカル部分を完全なリポジトリであるかのように操作します (開発者にはリポジトリ全体が表示されますが、要求されたデータのみがアクセスされるローカル システムにコピーされます)。
Facebook のインフラストラクチャで使用されるこれらのコンポーネントのコードはまだ公開されていませんが、同社は将来的にリリースすることを約束しています。 ただし、Mononoke サーバー (Rust の場合) と VFS EdenFS (C++ の場合) のプロトタイプは、Sapling リポジトリで既に見つけることができます。 これらのコンポーネントはオプションであり、Git リポジトリのクローン作成、Git LFS ベースのサーバーとの対話、GitHub などの git ホストの操作をサポートする Sapling クライアントで十分に機能します。
Saplingにはいくつかのプラグインが用意されていますこれには、変更をレビューするための ReviewStack インターフェイス (GPLv2 のコード) が含まれます。これにより、GitHub でプル リクエストを処理し、変更スタック ビューを使用できます。
あなたがそれについてもっと知りたいなら、あなたは詳細を調べることができます 次のリンクで。