アカウント名:
パスワード:
原理上、リポジトリ側にもクローンする側にも多大なる容量を要求するgitで、バイナリデータのバージョン管理をする意味がどこにあるんだろう?そもそもgitのバイナリデータの管理が苦手なのは、圧縮云々の問題じゃないだろう?Git LFSなんていう馬鹿馬鹿しい発明してる暇があるなら、Hgで言うところの--largeオプションをgitに実装するよう働きかけるべき。
ましてサーバ必須なんだったら、初めから自分用のSubversionでも立てて、バイナリデータはそっちで管理した方が遥かに楽だろ。バイナリデータのバージョン管理にgit使う必要は全くない。物事には適材適所というものがある。
Gitがバイナリデータに向かないというのはその通りですが、フォルダ毎に管理するSubversionも大きなバイナリデータに向きませんよ。バイナリ管理に向くのは、ファイル毎に管理し依存トラッキングを持つ次世代アセット管理システムです。オープンソースであれば、BlenderのBAM [blender.org]あたり。
まあLinuxのカーネル開発で巨大なバイナリblobを取り扱うことなんかそうそうないだろうから当然といえば当然だ
> 巨大なバイナリblob
頭痛が痛い表現ですね…。しかも Binary と Large で威力が2倍…
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
誰得 (スコア:0)
原理上、リポジトリ側にもクローンする側にも多大なる容量を要求するgitで、バイナリデータのバージョン管理をする意味がどこにあるんだろう?
そもそもgitのバイナリデータの管理が苦手なのは、圧縮云々の問題じゃないだろう?
Git LFSなんていう馬鹿馬鹿しい発明してる暇があるなら、Hgで言うところの--largeオプションをgitに実装するよう働きかけるべき。
ましてサーバ必須なんだったら、初めから自分用のSubversionでも立てて、バイナリデータはそっちで管理した方が遥かに楽だろ。
バイナリデータのバージョン管理にgit使う必要は全くない。物事には適材適所というものがある。
Re:誰得 (スコア:0)
Gitがバイナリデータに向かないというのはその通りですが、フォルダ毎に管理するSubversionも大きなバイナリデータに向きませんよ。
バイナリ管理に向くのは、ファイル毎に管理し依存トラッキングを持つ次世代アセット管理システムです。
オープンソースであれば、BlenderのBAM [blender.org]あたり。
Re: (スコア:0)
まあLinuxのカーネル開発で巨大なバイナリblobを取り扱うことなんかそうそうないだろうから当然といえば当然だ
Re:誰得 (スコア:1)
> 巨大なバイナリblob
頭痛が痛い表現ですね…。しかも Binary と Large で威力が2倍…