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

Question

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

我已被警告说，SVN并不是特别多的二进制文件。我很谨慎地尝试查看它是否有效，因为它们总是在存储库历史记录中，即使我后来删除它们也是如此。

任何替代方案？我们需要能够评论和/或标记文档，但我们可以使用类似美味的服务与SVN（或类似）中的文档的URL相结合。

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

Answer 1

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

Subversion存储'二进制增量'。实际上，在服务器端，二进制文件和文本文件在存储'delta'时完全相同。请查看第http://subversion.tigris.org/svn_1.4_releasenotes.html页上的“二进制增量编码改进”部分。它明确说明“ Subversion使用xdelta算法来计算字符串 ”之间的差异（而不是字符串'。字符'）。

为了实验，我存储了10版CAD（CATIA零件文件）。每个版本我对部分进行了少量修改，然后检查服务器端存储库大小。大约10个版本的总大小约为1.2倍（x - 是原始文件大小）。

请记住设置svn：needs-lock属性。根据我的经验，最好的方法是使用'auto props'来设置基于文件扩展名的svn：needs-lock。

Answer 2

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

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

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

因此;

• 1000 1MB文件=罚款。
• 100 10MB文件=罚款
• 10 100MB文件=罚款
• 1＆gt; 1000MB文件=不是个好主意。

我希望你的文件大小符合其中一个优良类别：）

Answer 3

我们为此构建了我们的subversion客户端，因为我们确实需要真正需要版本控制的大型设计/咨询工作。我们从未遇到任何问题。

Answer 4

这取决于文件更新的频率。它无法对合并二进制文件做任何事情，所以每当发生冲突时你都会感到痛苦。否则它只是存储和检索，虽然它不如文本那么好，但它仍处理得很好。

Answer 5

我个人使用Mercurial执行此类任务。我用它来存储几百个媒体。是的，它占用了一些磁盘空间，但磁盘空间很便宜。使用Mercurial，您还可以获得分发的好处，因此执行“结帐”或克隆，如Mercurial所知，您可以获得整个仓库，而不仅仅是快照。如果您的服务器已经死亡，那么您仍在营业。

Answer 6

据我所知，与Subversion相比，Git速度非常快，我听说它比Mercurial快一些，但只有一点点。但是，我没有使用大量或大量二进制文件对其进行专门测试。

据说Git跟踪变化的方式，我认为它在处理二进制文件方面非常有效。

我可以肯定地说这个;一旦我习惯了Git，我就无法选择回到Subversion。当我必须使用Subversion存储库时，我仍然使用Git git-svn。这样我就可以获得分布式版本控制的所有优点，但仍然可以很好地支持将提交推送回中央Subversion存储库。

Answer 7

好吧，它会占用很多存储在Subversion中的空间，我会告诉你的。 Subversion不会通过delta存储文本文件的方式存储二进制文件。它可能占用的空间与在硬盘驱动器上存储一堆二进制文件以及存储库一样多。

您可以在服务器端tiddlywiki中将URL存储到Subversion中的文档。

如果它们主要是.doc和.xls文件，那么还有微软的Sharepoint。