Metaが同社の大規模ソースコード管理システム「Sapling」をオープンソース化 26
ストーリー by nagazou
公開 部門より
公開 部門より
Metaが自社で使用してきたソースコード管理システム「Sapling」をオープンソース化した。2022年11月15日から一般向けに公開されている。Metaで使われるような大規模リポジトリの管理は一般的なソースコード管理システムでは難しいことから、このツールは同社が10年間にわたり開発・使用してきたという。リポジトリの把握、コミット、ミスの回復といったワークフローが大幅に容易になるよう作られていると説明している（Sapling公式、Engineering at Meta 、GIGAZINE）。
あるAnonymous Coward 曰く、
あるAnonymous Coward 曰く、
>Git互換で基本的なコマンドなどもGitに類似しているとのこと。Git一強な感じの昨今だが、比較してどうだろうか？
モノレポ (スコア:2, 興味深い)
大規模リポジトリというかモノリシックリポジトリという複数のプロジェクトを一つのレポジトリに入れてしまう管理手法に向いている。
最近流行らしい。
モノリシックなバージョン管理の利点
https://postd.cc/monorepo/ [postd.cc]
Re: (スコア:0)
リポジトリとレポジトリは別のものでしょうか?
Re: (スコア:0)
あちこちリンクしててリファクタリングが簡単になるって「Linuxカーネルの云々が安定していないのはメインラインに統合した方がリファクタリングがしやすいから」とかいう話に似てるなぁ。
まぁでも分かるよ。
依存関係にあるなら、複数プロジェクトを同じレポジトリで管理した方がリファクタリングは実際やりやすい。そして同期の問題も起きない。
全く違う理由だけど、書き捨てコードやお試しは専用レポジトリに放り込んでるな。
わざわざレポジトリ立ち上げるのもバラバラになるし、一応バージョン管理はしたいし。
これもモノリシックなバージョン管理と言えなくもないかもしれないけど多分言えない。
Re: (スコア:0)
メリットは分かるけど、センスのないチームが導入するとスパゲッティができそう。
Re: (スコア:0)
センスのないチームはGitであってもスパゲッティを作り上げます
Re: (スコア:0)
このスレッドはGitかどうかの話ではない。
Re: (スコア:0)
むしろセンスのない、自分たちのプロダクトが正しく動くための条件とかを
把握していないチームの方が導入メリットあると思う。
だって、保守などで過去のバージョンが必要になったとき、リポジトリの
リビジョンを指定するだけで正しくそのバージョンを取得できるんだから。
複数のリポジトリを使っている場合、センスのないチームだと、
依存するライブラリのリビジョンを固定していなかったり、
開発者各々が手作業で固定したりするんだから。
MSがgit押しになったから、、 (スコア:2)
https://devblogs.microsoft.com/bharry/the-largest-git-repo-on-the-planet/ [microsoft.com]
これとかも、Windowsソースをgitで管理してます(git+GVFS)、って話だし、
ファイルが350万あって、レポジトリサイズが300GBといわれると、gitで良いかな、ってなる
バイナリはどうなんでしょ (スコア:1)
Gitはバイナリファイルの取り扱いがいまいちで、ゲーム業界だと他のソースコード管理システムを使用するって話も聞くけどこれはどうなんだろう
Re:バイナリはどうなんでしょ (スコア:1)
ゲーム屋さんですが、確かにうちのクライアントチームやグラフィックチームはバイナリを扱うのでPerforce [perforce.com]とか言うの使ってますね。
なんかライセンス料はクソ高いらしいんですが、彼らは平気で大量の画像や、それどころかビルドしたバイナリ（デイリービルドで1日1GB）とかをバージョン管理に放り込んだりするので、Gitとかではうまく扱えないらしいです。
今回の奴の大規模というのがバイナリも想定してるなら、ワンチャン普及するかもしれませんね。
Re: (スコア:0)
Gitは、Linux Kernelのソースコード管理用に生まれた訳で、
GUI的なバイナリリソースが少ないプロジェクト向けな面は有りますよね。
Linusが、ゲーム開発にハマれば！？
Re: (スコア:0)
Metaがゲーム業界と同じようにバイナリをたくさん扱ってるかというとそうでもないのではないかと思う
基本的にはWebサイト運営でしょ
そりゃ画像とか動画はあるだろうけどさ
Re: (スコア:0)
Metaがゲーム業界寄りかどうかではなくて、Saplingのバイナリ対応はどうなんだろうかと
Re: (スコア:0)
いうてもこれは「Metaが自分で使うために作ったシステム」なので、必要としない部分に労力をかけていることを勝手に期待するのは虫が良すぎるかな
Re: (スコア:0)
subversionとかgitとかのバージョン管理システムって、どの箇所に変更があったのかを管理・追跡するためのシステムなので、
ファイルフォーマット上の都合で何らかのデータ圧縮がかかっているとか、
データの出現順序に明示的な意味がなかったりする(意味無く差分が生まれる)バイナリファイルって、
バージョン管理システムの想定対象外なんですよ。
管理上の都合で画像ファイルとか映像ファイルとかサウンドとかを突っ込みたがる輩が多くいますが、
これらに対する機能を期待しちゃいかんのです。
Re: (スコア:0)
だいたいあってるが
＞これらに対する機能を期待しちゃいかん
ここはあまり意味が無いコンサバな言いよう
その部分の機能性能がどのVCSでも横並びとは言えんし、また今後発達するべきではないとも言えない
なにせ画像・映像・サウンド以外、無秩序で制御不可能な差分を生まないバイナリはいくらでもあるのだから（当然その差分を視覚化する意義がある）
Re: (スコア:0)
そもそもバイナリの実用的なバージョン管理の要件としてファイル内差分を取り扱えることは必須ではないと思う。
現実的なパフォーマンスが出て、各バージョンのファイルを取り出せて、画像なら各バージョンを横に並べて確認できるだけでも「素材画像_20221121_最新.jpg」とかやるより圧倒的にいいわけだし。
Re: (スコア:0)
リポジトリのデータ総容量の低減とかを考えてるのでは？
全バージョンのファイルをそのまま持つより差分だけにしてくれた方がディスク使用量を減らせるでしょ。
バイナリの差分保存を実現してるバージョン管理システムが有るのかどうか知らないけど、
ファームウェアの差分アップデートの技術を使えば差分で管理できそうだけれども。
Re: (スコア:0)
いまいちどころかいまさんぐらいです正直。gitの設計思想は悪くないけどゲームデータとの相性がとにかく悪い。
PS以前から開発してるチームなら一度は独自VCSを構築したことがあるはず。
さすがに最近は独自ってとこは減って、営業上手なのかPerforceが導入されることが多いみたいですね。とくに大手。
大会社でも職種ごとにアカウント使い回しして使ってるくらいにはバカ高いのですが。
で、高い割に保守性とか事故率とかはlfsと大差ない。
お金も保守人員も限りのあるうちみたいな中小開発会社は、自前でgit+lfs構築してます。Lambda+s3を使いつつ認証だけgithub api。オススメです。githubオフィシャルのLFSは高いからナシ。
さすがにsvnはもう使わない……かといえば現役なところもある。
gitは難しいからって言ってるけど、そんな開発力で大丈夫か。
メタメタなものなんか使わない (スコア:0)
Gitでいいですよ。
Re: (スコア:0)
Metaがリストラで開発を維持できなくなったからオープンソースにしたんじゃないか、という気がしている。
Gitに比較して部分的に優れているところが、Gitの開発にフィードバックされていって、そのままフェードアウトしそう。
なんでGithub上でSaplingのコード管理をするのだろう (スコア:0)
Sapling上でSaplingのコード管理をすべきでしょう。
それはそう (スコア:0)
でもGitとGitHubは別物だからね。そのうちSaplingHubみたいなウェブサービス作るのでは？
git か Sapling かを気にしている時点で考え方が古い (スコア:0)
> Sapling上でSaplingのコード管理をすべきでしょう。
分散システムなんだから、リポジトリの場所(URL)とか、そのプロトコル(git or sapling)にこだわるのなんてナンセンスですよ。考えが古い。
実用上の問題を考えると、開発者はまずソースコードを入手したいと思うわけだけどSaplingのクライアント（バイナリ）なんて持ってない。 git なら持ってる。現時点で開発者目線で考えれば git で公開してもらったほうが便利です。
加えて Sapling のクライアントはgitのリ
slコマンド (スコア:0)
lsを打ち間違えても蒸気機関車を走らせられなくなってしまう
Re: (スコア:0)
これからの時代は line コマンドでしょう