我正在寻找一个放置几 GB 文件的地方（主要是.doc和.xls）。我的团队已经设置了一个 Subversion 服务器来管理我们创建的文档，所以如果可能的话，我更愿意使用它。Subversion 将如何处理所有这些额外的东西？其中大部分是遗留信息，并且永远只有一个版本，但有可能会更新一些文档。
我被警告过，SVN 并不是特别多的大二进制文件友好。我很谨慎地尝试它来查看它是否有效，因为即使我后来删除它们，它们也将始终存在于存储库历史记录中。
有什么选择吗？我们需要评论和/或标记文档的能力，但我们可以使用类似 Delicious 的服务与 SVN（或类似）中文档的 URL 相结合。
后来 我不再担心二进制文件的差异，因为如上所述，它们不会有太大变化。如果他们这样做，我可以稍微麻烦一些——它并不比 SharePoint 差。
在我以前的公司，我们设置 Subversion 来存储 CAD 文件。高达 100 MB 的文件存储在 Subversion 中。如果很多人向 Subversion 网络服务器“添加”大文件可能会成为瓶颈。但是，增量提交完全没问题。
Subversion 存储了“二进制增量”。事实上，在服务器端，二进制文件和文本文件在存储“增量”时的处理方式完全相同。检查页面http://subversion.tigris.org/svn_1.4_releasenotes.html上的“二进制增量编码改进”部分。它明确表示“ Subversion 使用 xdelta 算法来计算字节字符串之间的差异”（而不是“字符”字符串'）。
只是为了实验，我存储了 10 版本的 CAD（CATIA 零件文件）。每个版本我都对部分进行了微小的修改，然后检查服务器端存储库的大小。大约 10 个修订版的总大小约为 1.2 倍（x - 是原始文件大小）。
记得设置 svn:needs-lock 属性。根据我的经验，最好的方法是使用“自动道具”来设置基于文件扩展名的 svn:needs-lock。
大量大二进制文件和大量二进制文件之间存在差异。
根据我的经验，SVN 可以处理数百兆字节的单个二进制文件。我看到的唯一问题开始出现在大约 1 GB 左右的单个文件中。由于神秘和未知的原因导致操作失败，可能是 SVN 无法处理与网络相关的问题。
我不知道任何与二进制文件数量相关的 SVN 问题，除了它们缺乏合并能力以及二进制文件通常不能有效地存储为增量（SVN 可以使用增量）的事实。
所以;
我希望您的文件大小适合其中的一个好类别:)
我们正是为此构建了我们的颠覆客户端，因为我们做了真正需要版本控制的大型设计/咨询工作。我们从来没有遇到过任何问题。
这取决于文件的更新频率。它对合并二进制文件无能为力，因此每次发生冲突时都会感到痛苦。否则它只是存储和检索，虽然它不如文本好，但它仍然可以处理得很好。
我个人将 Mercurial 用于此类任务。我已经用它来存储数百场媒体。是的，它占用了一些磁盘空间，但磁盘空间很便宜。使用 Mercurial，您还可以获得分发它的好处，因此进行“结帐”或按照 Mercurial 中已知的克隆，您将获得整个 repo，而不仅仅是快照。如果您的服务器死了，那么您仍在营业。
从我所见，与 Subversion 相比，Git 非常快，而且我听说它比 Mercurial 快一些，但只是快了一点。但是，我没有专门用大型或大量二进制文件对其进行测试。
话虽如此，Git 跟踪更改的方式，我想它在处理二进制文件方面非常有效。
不过，我可以肯定地说；一旦我习惯了 Git，我就不会选择回到 Subversion。当我必须使用 Subversion 存储库时，我仍然通过 git-svn 使用 Git。通过这种方式，我获得了分布式版本控制的所有优势，但仍然非常支持将提交推送回中央 Subversion 存储库。
好吧，在 Subversion 中存储所有内容会占用大量空间，我会告诉你这么多。Subversion 不会像存储文本文件那样通过 delta 存储二进制文件。它可能会占用与仅在硬盘驱动器上存储一堆二进制文件以及存储库一样多的空间。
您可以在服务器端 tiddlywiki 将 URL 存储到 Subversion 中的文档。
如果它们主要是 .doc 和 .xls 文件，还有微软的 Sharepoint。