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