アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
バイナリ中心で使えます? (スコア:3, 興味深い)
そりゃ更新履歴が全部ローカルにあれば色々嬉しいのは自明っちゃ自明だし、そんな発想が成り立つほどネットワークもストレージも安価になりましたが…
にしても、某OSのカーネルの100MB程度ならともかく、今うちにある「最新リビジョンが1GBで、リポジトリは1ヶ月で数GB増えた」という画像やDTPデータ主体のSubversionリポジトリが、Hgとかに移行して普通に動いてくれるのか心配です。
メンバーに未だにテレホユーザという人がいて、分散リポジトリ自体は本来そういう人のためにあるのだと思いますが、彼にとって1GBならギリギリだけど、10GBだと始まる前から終わってます。(リポジトリのpartial cloneができたり、headとログメッセージだけのcloneとかができる?)
Re:バイナリ中心で使えます? (スコア:1)
そもそも、衝突解消のツールがなければ、バージョン管理はロック方式でないとならないのではないでしょうか。
Re:バイナリ中心で使えます? (スコア:1)
10MBのビットマップの一部のゴミを取り除いただけとか、3MBのDTPファイルの1文字誤植を修正しただけで(差分ではなく)全体が格納されてたんじゃ、うちのSVNの数GBのリポジトリはhgにコンバートした瞬間に更に数倍に膨れそうです。
というか、あ、hgやSVKには原理上ロックの仕組みそのものがないんですね(まぁ当然素のSVNにはありますが)。うーん分散しすぎるのも困った。マージ履歴とローカルでのコミットだけでも欲しかったのに。
(バイナリでファイル単位のマージは不可能でも、8割型共通で「関東版」「関東版」でちょっと違う本とかをブランチで管理するときに、共通部分の誤植訂正を追いかけてみたかった)
Re:バイナリ中心で使えます? (スコア:1)
手持ちの xls ファイルを少しいじって commit したところ、およそ50%程度のデータファイルが出来ています。
そこから更に変更をcommitしていっても極端な大きさにはならないようです。
ただし素の Mercurial は扱えるファイルサイズの上限が 10MB にハードコーディングされている為、大きなファイルを扱う場合には localrepo.py の該当箇所を適時修正する必要があるでしょう。
Re:バイナリ中心で使えます? (スコア:2, 参考になる)
10MB超えると警告は出ますが、そのまま普通にCommitかければ通りますが・・・・・・。
(100MB超のファイルでも問題ありませんでした。)
Re:バイナリ中心で使えます? (スコア:1)
警告と上限を勘違いしていたようです。