パスワードを忘れた? アカウント作成
12004408 story
プログラミング

GitHub、「Git Large File Storage」を発表 13

ストーリー by hylom
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サーバーのホスティングをサービスとして行うようだ。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2015年04月09日 21時55分 (#2794011)

    原理上、リポジトリ側にもクローンする側にも多大なる容量を要求するgitで、バイナリデータのバージョン管理をする意味がどこにあるんだろう?
    そもそもgitのバイナリデータの管理が苦手なのは、圧縮云々の問題じゃないだろう?
    Git LFSなんていう馬鹿馬鹿しい発明してる暇があるなら、Hgで言うところの--largeオプションをgitに実装するよう働きかけるべき。

    ましてサーバ必須なんだったら、初めから自分用のSubversionでも立てて、バイナリデータはそっちで管理した方が遥かに楽だろ。
    バイナリデータのバージョン管理にgit使う必要は全くない。物事には適材適所というものがある。

    • by Anonymous Coward

      俺たちの任天堂が使っているAlienBrainでGitを殺そう
      Gitをこの世から消滅させよう
      10年もたったんだ、もういいだろう、Gitの次が出てきても

      • by Anonymous Coward

        VCSはだいたい10年ごとに新しいのに変わっているという言説を以前見かけたな。それに従えば確かに頃合いだ

      • by Anonymous Coward

        AlienBrainは流石に古過ぎますよ…。新しいVCSはないのかというと、Plastic SCMがそれです。
        ゲーム開発に向くと謳うPlastic SCMは近年Unityとの連携で話題となっており、分散型なのに排他的チェックアウトが可能というポストGitに相応しいものですが、
        依存追跡機能が無いので次世代とまでは言い難く、映像系のパイプラインのアセット管理では使われていない…という認識です。

    • by Anonymous Coward

      自分でサーバーが立てられない人は開発を始める権利がないってこと?

      gitでプロジェクト全体が管理できた方が便利に決まっているだろう。ソースコードと他のリソースを別々のソフトで管理するのは、面倒を増やすだけで、有体に言ってバグのもとだよ。自分がgitとsvnを使ったら、周りの全員がそうしなければいけないということの意味をよく考えた方がいい。

    • by Anonymous Coward

      Gitがバイナリデータに向かないというのはその通りですが、フォルダ毎に管理するSubversionも大きなバイナリデータに向きませんよ。
      バイナリ管理に向くのは、ファイル毎に管理し依存トラッキングを持つ次世代アセット管理システムです。
      オープンソースであれば、BlenderのBAM [blender.org]あたり。

  • by Anonymous Coward on 2015年04月10日 1時02分 (#2794060)

    >リポジトリのサイズが大きくなったり、
    これはわかる。しかし
    >各種操作に時間がかかる
    エーナンデー

    オブジェクトはハッシュでIDつけられて変更の検出とかに使われてると思ってた。
    つまり一度ハッシュを取れば本体はディスクの肥やしになるだけで処理時間とは無関係だと思ってた。

    そして、サイズが関係する操作としてdiffとかpullとかmergeとか色々あるけどblobにdiffとかないわぁ。
    何か自分が知らない機能要件ではオブジェクトを別管理するという対策で処理が効率化したりするの?
    そこんとこ誰か教えて。

    • by Anonymous Coward

      gitはaddしたタイミングでaddした部分全体のスナップショットを持ってる。つまり、diffしてないんだけど、いつdiffが呼ばれても高速でdiffが表示できる準備が整っている。こういうローカルなスナップショットはその都度作ったり消したりするんじゃなくて、ガベージコレクションで運用されてるから、要らなくなった瞬間に消えうせるわけじゃない。

      あと、pullやpushで同期するときはネットを通る部分にzlibで圧縮をかけていて、これも遅くなる原因だったような。

      • by Anonymous Coward

        機能要件ありがとう。
        でも、その上でもう一度聞くけど、それはオブジェクトを別管理するという対策で処理が効率化したりするの?

        • by Anonymous Coward

          横から。

          機能要件ありがとう。
          でも、その上でもう一度聞くけど、それはオブジェクトを別管理するという対策で処理が効率化したりするの?

          Git LFS のドキュメントと #2794073 を併せて考えれば自明なので
          Git が各種処理で実際に何をやっているか理解されていないように思います。

          Git / Git LFS のコードや内部解説のドキュメントに少しだけでも目を通すことをお勧めします。

typodupeerror

長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds

読み込み中...