version-control - 大文件的版本控制系统？

Question

我正在寻找一种快速但不那么脏的方法来对总共大约 80 个演出的一堆文件进行快照。这里的问题是许多文件都在 1 GB 左右。

这类事情最好的免费版本控制系统是什么？

我知道 ZFS 是一种选择，但我宁愿先尝试其他方法。

Answer 1

Subversion 将在大多数情况下以良好的本性沉着处理你的 > 1GB 文件，但如果有很多大的变化，预计差异的生成需要一段时间......

Subversion Best practices有一个关于大文件的部分:

A nice feature of Subversion is that by design, there is no limit to the size of files it can handle. Files are sent "streamily" in both directions between Subversion client and server, using a small, constant amount of memory on each side of the network.

Of course, there are a number of practical issues to consider. While there's no need to worry about files in the kilobyte-sized range (e.g. typical source-code files), committing larger files can take a tremendous amount of both time and space (e.g. files that are dozens or hundreds of megabytes large.)

To begin with, remember that your Subversion working copy stores pristine copies of all version-controlled files in the .svn/text-base/ area. This means that your working copy takes up at least twice as much disk space as the original dataset. Beyond that, the Subversion client follows a (currently unadjustable) algorithm for committing files:

. Copies the file to .svn/tmp/ (can take a while, and temporarily uses extra disk space))

. Performs a binary diff between the tmpfile and the pristine copy, or between the tmpfile and an empty-file if newly added. (can take a very long time to compute, even though only a small amount of data might ultimately be sent over the network)

. Sends the diff to the server, then moves the tmpfile into .svn/text-base/

So while there's no theoretical limit to the size of your files, you'll need to be aware that very large files may require quite a bit of patient waiting while your client chugs away. You can rest assured, however, that unlike CVS, your large files won't incapacitate the server or affect other users.