East River Source Controlは、チームに既存のGitクライアントを捨てるよう強いることなく、リポジトリの肥大化と開発負荷の増大に対処することを目的としたソース管理プラットフォームのアーキテクチャを明らかにした。同社はまだ製品を公開していないが、そのシステムではGitプロトコルを受け付けつつ、コードを従来型のGitリポジトリではなく独自のバックエンドに保存するとしている。
この互換性優先のアプローチは、提案の中核を成している。Gitは開発ツールや運用手法全体に深く組み込まれており、別のバージョン管理システムへ急に移行するのは危険を伴う。ERSCによると、ユーザーは通常のGitソフトウェアで接続し続けられるため、組織はすべての開発者を同時に再教育したり、統合機能を置き換えたりせずにサーバーのアーキテクチャを変更できる。
同社は、AI支援型の開発により、これまで非常に大規模なエンジニアリング組織に集中していたスケーリング上の圧力が表面化していると主張する。エージェントは変更やブランチを増やし、マージの競合を増加させる可能性があるほか、広範なコードへのアクセスが有用なコンテキストを提供するため、モノレポを選好する。クラウドベースの分離された開発環境によって、高速なクローン作成と予測可能なリポジトリアクセスの重要性も高まっている。これらは同社による市場評価であり、独立した性能調査の結果ではない。
サーバー側では、ERSCはシステム・オブ・レコードとしてのディスクベースのGitリポジトリを、水平スケーリング可能なストレージエンジンに置き換える計画だ。導入環境は1つのグローバルプラットフォームを共有するのではなく顧客ごとに分離される。同社によると、この設計は管理能力を高め、別の顧客のワークロードが可用性に影響するリスクを軽減するはずだ。GraphQLインターフェースも、同社が説明するより広範なアーキテクチャの一部である。
ERSCはさらに、将来のプロトコルへの橋渡し役としてJujutsu（jj）を検討している。Jujutsuではすでに、Gitバックエンドを使って同ソフトウェアのワークフローを利用できるため、同僚がGitを使い続ける一方で、個人がJujutsuを採用できる。ERSCは、この段階的な移行をサーバー側でも再現することを提案している。顧客はGitクライアントから使い始め、その後、同じ基盤ストレージエンジンに対して別のプロトコルを利用できる可能性がある。
この構想の重要な部分は、依然として将来の計画にとどまっている。現在、アップストリームにはJujutsuネイティブのプロトコルは存在せず、ERSCもそのような対応がすでに存在すると主張しているわけではないことを明言している。同社によると、プロトコル関連の作業を行う場合は文書化し、コミュニティーと共同で開発した必要なクライアント変更はオープンソース化する。
したがって、この情報開示は完成製品の発表ではなく、アーキテクチャに関する声明である。開発者がすでに利用しているインターフェースを維持しながら、その下のストレージを変更するという現実的な導入戦略を示しているが、本番環境のベンチマーク、顧客への導入実績、公開日は提示していない。提案されたシステムがERSCの説明する信頼性と拡張性を実現できるかどうかは、そうした詳細によって決まる。
