GitHub、「Git Large File Storage」を発表 13
ストーリー by hylom
GitHubユーザー的には便利かも？ 部門より
GitHubユーザー的には便利かも？ 部門より
insiderman 曰く、
GitHubがGit Large File Storage（Git LFS）なるソフトウェアを公開した（GitHubのリポジトリ）。Webサイトの説明によると、オーディオや動画、データ集、グラフィックといった大きなファイルをGitで扱いやすくするためのソフトウェアだという。
Gitでは、バージョン管理対象のファイルをリポジトリ内に圧縮された形で保持している。そのため、バイナリデータをバージョン管理しようとするとリポジトリのサイズが大きくなったり、各種操作に時間がかかるようになってしまう傾向がある。Git LFSではバイナリデータを別のストレージ（Git LFS Server）に分離して保存し、そこへの参照（ポインタ）のみをリポジトリ内に格納することでこの問題を解決するというもののようだ。
Git LFSはGitのプラグイン（機能拡張）として作成されており、「git lfs」サブコマンドで機能が利用できるようだ。なお、利用には別途Git LFSサーバーが必要となる。スタンドアロンで動作する「lfs-test-server」が公開されているほか、GitHub自身もGit LFSサーバーのホスティングをサービスとして行うようだ。
誰得 (スコア:0)
原理上、リポジトリ側にもクローンする側にも多大なる容量を要求するgitで、バイナリデータのバージョン管理をする意味がどこにあるんだろう？
そもそもgitのバイナリデータの管理が苦手なのは、圧縮云々の問題じゃないだろう？
Git LFSなんていう馬鹿馬鹿しい発明してる暇があるなら、Hgで言うところの--largeオプションをgitに実装するよう働きかけるべき。
ましてサーバ必須なんだったら、初めから自分用のSubversionでも立てて、バイナリデータはそっちで管理した方が遥かに楽だろ。
バイナリデータのバージョン管理にgit使う必要は全くない。物事には適材適所というものがある。
Re: (スコア:0)
俺たちの任天堂が使っているAlienBrainでGitを殺そう
Gitをこの世から消滅させよう
10年もたったんだ、もういいだろう、Gitの次が出てきても
Re: (スコア:0)
VCSはだいたい10年ごとに新しいのに変わっているという言説を以前見かけたな。それに従えば確かに頃合いだ
Re: (スコア:0)
AlienBrainは流石に古過ぎますよ…。新しいVCSはないのかというと、Plastic SCMがそれです。
ゲーム開発に向くと謳うPlastic SCMは近年Unityとの連携で話題となっており、分散型なのに排他的チェックアウトが可能というポストGitに相応しいものですが、
依存追跡機能が無いので次世代とまでは言い難く、映像系のパイプラインのアセット管理では使われていない…という認識です。
Re: (スコア:0)
あれだって8年目か
Re: (スコア:0)
自分でサーバーが立てられない人は開発を始める権利がないってこと？
gitでプロジェクト全体が管理できた方が便利に決まっているだろう。ソースコードと他のリソースを別々のソフトで管理するのは、面倒を増やすだけで、有体に言ってバグのもとだよ。自分がgitとsvnを使ったら、周りの全員がそうしなければいけないということの意味をよく考えた方がいい。
Re: (スコア:0)
Gitがバイナリデータに向かないというのはその通りですが、フォルダ毎に管理するSubversionも大きなバイナリデータに向きませんよ。
バイナリ管理に向くのは、ファイル毎に管理し依存トラッキングを持つ次世代アセット管理システムです。
オープンソースであれば、BlenderのBAM [blender.org]あたり。
Re: (スコア:0)
まあLinuxのカーネル開発で巨大なバイナリblobを取り扱うことなんかそうそうないだろうから当然といえば当然だ
Re:誰得 (スコア:1)
> 巨大なバイナリblob
頭痛が痛い表現ですね…。しかも Binary と Large で威力が2倍…
教えて (スコア:0)
>リポジトリのサイズが大きくなったり、
これはわかる。しかし
>各種操作に時間がかかる
ｴｰﾅﾝﾃﾞｰ
オブジェクトはハッシュでIDつけられて変更の検出とかに使われてると思ってた。
つまり一度ハッシュを取れば本体はディスクの肥やしになるだけで処理時間とは無関係だと思ってた。
そして、サイズが関係する操作としてdiffとかpullとかmergeとか色々あるけどblobにdiffとかないわぁ。
何か自分が知らない機能要件ではオブジェクトを別管理するという対策で処理が効率化したりするの？
そこんとこ誰か教えて。
Re: (スコア:0)
gitはaddしたタイミングでaddした部分全体のスナップショットを持ってる。つまり、diffしてないんだけど、いつdiffが呼ばれても高速でdiffが表示できる準備が整っている。こういうローカルなスナップショットはその都度作ったり消したりするんじゃなくて、ガベージコレクションで運用されてるから、要らなくなった瞬間に消えうせるわけじゃない。
あと、pullやpushで同期するときはネットを通る部分にzlibで圧縮をかけていて、これも遅くなる原因だったような。
Re: (スコア:0)
機能要件ありがとう。
でも、その上でもう一度聞くけど、それはオブジェクトを別管理するという対策で処理が効率化したりするの？
Re: (スコア:0)
横から。
機能要件ありがとう。
でも、その上でもう一度聞くけど、それはオブジェクトを別管理するという対策で処理が効率化したりするの？
Git LFS のドキュメントと #2794073 を併せて考えれば自明なので
Git が各種処理で実際に何をやっているか理解されていないように思います。
Git / Git LFS のコードや内部解説のドキュメントに少しだけでも目を通すことをお勧めします。