Facebook (ロシア連邦では禁止されている) は、社内プロジェクトの開発に使用される Sapling ソース管理システムを公開しました。 このシステムは、数千万のファイル、コミット、ブランチにまたがる非常に大規模なリポジトリに対応できる、使い慣れたバージョン管理インターフェイスを提供することを目的としています。 クライアント コードは Python と Rust で書かれており、GPLv2 ライセンスの下で公開されています。
サーバー部分は、リポジトリとリポジトリの一部のローカル スライスを完全なリポジトリとして操作するための仮想ファイル システムを使用した効率的なリモート作業のために個別に開発されました (開発者にはリポジトリ全体が表示されますが、アクセスされる必要なデータのみが表示されます)。ローカル システムにコピーされます)。 Facebookのインフラストラクチャで使用されるこれらのコンポーネントのコードはまだ公開されていないが、同社は将来公開すると約束している。 ただし、現在、Sapling リポジトリには、Mononoke サーバー (Rust) と VFS EdenFS (C++) のプロトタイプがすでに見つかります。 これらのコンポーネントはオプションであり、Git リポジトリのクローン作成、Git LFS ベースのサーバーとの対話、GitHub などの Git ホスティング サイトとの連携をサポートする Sapling クライアントで十分に機能します。
このシステムの主な考え方は、リポジトリのストレージを提供する特別なサーバー部分と対話するときに、開発者が作業しているコードで実際に使用されるファイルの数に応じてすべての操作がスケールされ、依存しないということです。リポジトリ全体の合計サイズ。 たとえば、開発者は非常に大規模なリポジトリからコードのごく一部だけを使用し、リポジトリ全体ではなく、その小さな部分だけがシステムに移行される場合があります。 作業ディレクトリは、リポジトリのファイルがアクセスされると動的に埋められます。これにより、コードの一部の作業を大幅に高速化できる一方で、新しいファイルにアクセスするときに速度が低下します。初めて実行するため、ネットワークへの常時アクセスが必要です (コミットを準備するために別途提供されるオフライン モード)。
Sapling は、適応的なデータ ロードに加えて、変更履歴に関する情報のロードを削減することを目的とした最適化も実装しています (たとえば、Linux カーネルのリポジトリ内のデータの 3/4 は変更履歴です)。 変更履歴を効果的に操作するために、変更履歴に関連付けられたデータはセグメント化された表現で保存され、これによりコミット グラフの個々の部分をサーバーからダウンロードできるようになります。 クライアントは、複数のコミット間の関係に関する情報をサーバーに要求し、グラフの必要な部分のみをダウンロードできます。
このプロジェクトは過去 10 年にわたって開発されており、「マージ」の代わりに「リベース」操作を使用する XNUMX つのマスター ブランチを持つ非常に大規模なモノリシック リポジトリへのアクセスを整理する際の問題を解決するために作成されました。 当時、そのようなリポジトリを操作するためのオープン ソリューションは存在しませんでした。Facebook のエンジニアは、プロジェクトを小さなリポジトリに分割する代わりに、会社のニーズを満たす新しいバージョン管理システムを作成することにしました。依存関係の管理 (かつて、同様の問題を解決するために、Microsoft は GVFS レイヤーを作成しました)。 当初、Facebook は Mercurial システムと、Mercurial への追加として開発された第 XNUMX 段階の Sapling プロジェクトを使用していました。 時間が経つにつれて、システムは独自のプロトコル、ストレージ形式、アルゴリズムを備えた独立したプロジェクトに変化し、Git リポジトリと対話する機能も拡張されました。
作業用には、Git や Mercurial に精通した開発者にとって馴染みのある典型的な概念、ワークフロー、インターフェイスを実装したコマンド ライン ユーティリティ「sl」が提供されます。 Sapling の用語とコマンドは Git とは若干異なり、Mercurial に近いです。 たとえば、ブランチの代わりに「ブックマーク」が使用されます (名前付きブランチはサポートされていません)。デフォルトでは、クローン/プルを実行するときに、リポジトリ全体がロードされるのではなく、メイン ブランチのみがロードされます。コミットの予備的なマーキングはありません (ステージング領域)、「git fetch」の代わりに「sl」コマンドが使用されます。「git pull」の代わりに「pull」 - 「git checkout COMMIT」の代わりに「sl pull -rebase」 - 「sl goto COMMIT」の代わりに「git reflog」 - 「slジャーナル」では、変更をキャンセルするために「git checkout - FILE」の代わりに「sl revert FILE」を指定し、「.」は「HEAD」ブランチを識別するために使用されます。 ただし、一般に、ブランチとクローン/プル/プッシュ/コミット/リベース操作の一般的な概念は維持されます。
Sapling ツールキットの追加機能の中でも、リポジトリの状態を視覚的に評価し、最も重要な情報を強調表示し、重要でない詳細を除外できる「smartlog」のサポートが際立っています。 たとえば、引数なしで sl ユーティリティを実行すると、独自のローカル変更のみが画面に表示され (その他は最小化されます)、外部ブランチの状態、変更されたファイル、およびコミットの新しいバージョンが表示されます。 さらに、インタラクティブな Web インターフェイスが提供されており、スマート ログ内をすばやく移動し、ツリーを変更し、コミットすることができます。
Sapling のもう XNUMX つの注目すべき改良点は、エラーの修正と解決、および以前の状態への復帰が容易になったことです。 たとえば、コマンド「sl undo」、「sl redo」、「sl uncommit」、および「sl unamend」は多くの操作をロールバックするために提供され、コマンド「sl Hide」および「sl unhide」はコミットを一時的に非表示にするために使用されます。また、古い状態を対話的にナビゲーションし、「sl undo -i command」コマンドを使用して指定したポイントに戻ります。 Sapling は、コミット スタックの概念もサポートしています。これにより、複雑な機能を、より小さく、より理解しやすい段階的な変更 (基本フレームワークから完成した機能まで) に分割することで、段階的なレビューを整理できます。
Sapling には、変更をレビューするための ReviewStack インターフェイス (GPLv2 に基づくコード) など、いくつかの追加機能が用意されています。これにより、GitHub でプル リクエストを処理し、変更のスタック ビューを使用できるようになります。 さらに、VSCode および TextMate エディターとの統合、および ISL (Interactive SmartLog) インターフェイスとサーバーの実装に関する追加機能が公開されました。
出所： オープンネット.ru