Subversion在存储大量二进制文件方面有多好？

我正在寻找一个放置几GB文档的地方(主要是.doc和.xls).我的团队已经设置了Subversion服务器来管理我们创建的文档,所以如果可能的话,我更愿意使用它.Subversion如何处理所有这些额外的东西？其中大部分是遗留信息,并且只有一个版本,但可能会更新一些文档.

我已经被警告过,SVN并不是特别容易使用的二进制文件.我很谨慎尝试它是否有效,因为它们总是在存储库历史记录中,即使我后来删除它们也是如此.

任何替代品？我们需要能够评论和/或标记文档,但我们可以使用类似于美味的服务与SVN(或类似)中的文档的URL相结合.

后来 我不太担心二进制文件的差异,因为如上所述,它们不会有太大变化.如果他们这样做的话我会有轻微的麻烦 - 这并不比SharePoint差.

在我以前的公司中,我们设置了Subversion来存储CAD文件.最高100 MB的文件存储在Subversion中.如果很多人将"大文件"添加到Subversion网络服务器可能是一个瓶颈.但是,增量提交完全没问题.

Subversion存储了'二进制增量'.事实上,在服务器端,二进制文件和文本文件在存储'delta'时完全相同.检查页面http://subversion.tigris.org/svn_1.4_releasenotes.html上的"二进制增量编码改进"部分.它明确说明" Subversion使用xdelta算法来计算字节字符串之间的差异 "(而不是'字符串' ").

仅仅为了实验,我存储了10版CAD(CATIA零件文件).每个版本我对部分进行了少量修改,然后检查服务器端存储库大小.对于大约10个修订版,总大小约为1.2x(x - 是原始文件大小).

记得设置svn:needs-lock属性.根据我的经验,最好的方法是使用'auto props'来设置基于文件扩展名的svn:needs-lock.

许多大二进制文件和大量二进制文件之间存在差异.

根据我的经验,SVN适用于几百兆字节的单个二进制文件.我看到的唯一问题开始出现在大约一千兆字节左右的单个文件中.操作由于神秘和未知原因而失败,可能SVN无法处理与网络相关的问题.

我不知道任何与二进制文件数量有关的SVN问题,除了缺乏合并能力以及二进制文件通常无法有效存储为增量(SVN可以使用增量)这一事实.

所以;

1000个1MB文件=很好.

100个10MB文件=很好

10个100MB文件=很好

1> 1000MB文件=不是个好主意.

我希望您的文档大小适合其中一个优秀的类别:)