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