在git中对大文本文件进行版本控制

use*_*774 14 git

我已经使用git一段时间来进行源代码控制了,我真的很喜欢它.所以我开始调查使用git来存储大量的二进制文件,我发现这不是git的一杯茶.那么大文本文件呢?似乎git应该处理那些就好了,但我也遇到了问题.

我正在使用550mb大小的mbox样式文本文件测试它.我git init'ed新的回购做这件事.这是我的结果:

  • git add和git commit - 总回购大小为306mb - repo包含一个大小为306mb的对象
  • 添加一封电子邮件到邮箱文件和git commit - 总回购大小为611mb - repo包含两个对象,每个对象大小为306mb
  • 再添加一封电子邮件到邮箱文件和git commit - 总回购大小为917mb - repo包含三个对象,每个对象大小为306mb

因此,每次提交都会将邮箱文件的新副本添加到repo中.现在我想尝试将回购的大小降低到易于管理的程度.这是我的结果:

  • git repack -adf - 总回购大小为877mb - repo包含一个大小为876mb的包文件
  • git gc --aggressive - 总回购大小是877mb - repo包含一个大小为876mb的包文件

我希望能够将回购的大小缩小到306mb左右,但我无法弄清楚如何.任何更大的东西似乎都存储了很多重复的数据.

我希望回购只会增加收到的新电子邮件的大小,而不是整个邮箱的大小.我不是试图在这里控制电子邮件的版本,但这似乎是我使用夜间脚本逐步备份用户主目录的重大阻碍.

有关如何在将大量文本插入到非常大的文本文件末尾时保持repo大小不被破坏的任何建议?

我看过bup和git附件,但是如果可能的话,我真的很想坚持使用普通的git.

谢谢您的帮助!

Sch*_*ern 5

Git 不是最好的备份工具,但它应该能够非常有效地处理向文本文件的追加。我对你的结果表示怀疑。我在 OS X 上使用 354 meg 文件和 git 1.7.7 重复了您的实验。这是我的操作和 .git 的大小。

  1. git 初始化 (52K)
  2. git add mbox && git commit (110M)
  3. cat mail1 >> mbox && git commit -a -m (219M)
  4. git GC (95M)
  5. cat mail2 >> mbox && git commit -a -m (204M)
  6. git GC (95M)

正如您所看到的,git 非常高效。94 兆是压缩后的 mbox 的大小。它不可能变得更小。

我猜你要么使用旧版本的 git,要么你的 mbox 文件被你的邮件程序压缩或加密。

  • 检查 git 看到的 mbox 内容是否是纯文本。
  • 如果您没有使用最新的 git,请升级并重试。


Rya*_*son 3

我不认为 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。