我已经使用git一段时间来进行源代码控制了,我真的很喜欢它.所以我开始调查使用git来存储大量的二进制文件,我发现这不是git的一杯茶.那么大文本文件呢?似乎git应该处理那些就好了,但我也遇到了问题.
我正在使用550mb大小的mbox样式文本文件测试它.我git init'ed新的回购做这件事.这是我的结果:
因此,每次提交都会将邮箱文件的新副本添加到repo中.现在我想尝试将回购的大小降低到易于管理的程度.这是我的结果:
我希望能够将回购的大小缩小到306mb左右,但我无法弄清楚如何.任何更大的东西似乎都存储了很多重复的数据.
我希望回购只会增加收到的新电子邮件的大小,而不是整个邮箱的大小.我不是试图在这里控制电子邮件的版本,但这似乎是我使用夜间脚本逐步备份用户主目录的重大阻碍.
有关如何在将大量文本插入到非常大的文本文件末尾时保持repo大小不被破坏的任何建议?
我看过bup和git附件,但是如果可能的话,我真的很想坚持使用普通的git.
谢谢您的帮助!
Git 不是最好的备份工具,但它应该能够非常有效地处理向文本文件的追加。我对你的结果表示怀疑。我在 OS X 上使用 354 meg 文件和 git 1.7.7 重复了您的实验。这是我的操作和 .git 的大小。
正如您所看到的,git 非常高效。94 兆是压缩后的 mbox 的大小。它不可能变得更小。
我猜你要么使用旧版本的 git,要么你的 mbox 文件被你的邮件程序压缩或加密。
我不认为 git 在存储增量方面做得很好,即使你可以欺骗它这样做,它也不会是确定性的。也就是说,根据http://metalinguist.wordpress.com/2007/12/06/the-woes-of-git-gc-aggressive-and-how-git-deltas-work/,您可能想尝试一下git repack -a -d --depth=250 --window=250。
我怀疑你最好的选择是使用 git --rebase 截断你的历史记录,并且只存储过去的几个备份。您可以使用 git 分支来完成此操作。创建一个分支,称为每年、每月和每日。每天,承诺每天,然后用于git rebase --onto HEAD~4 HEAD~3 daily删除超过 3 天的备份。在每周的第一天,每周检查一次git cherry-pick daily,然后执行相同的 git rebase 删除超过 3 周的每周备份。最后,在每年的第一天,遵循类似的过程。您可能希望git gc每次都在此序列之后执行 a 以释放旧空间。
但如果你这样做,你就不再利用 git 并大量滥用它的工作方式。我认为最适合你的备份解决方案不涉及 git。