使用Subversion作为工件存储库而不是特定的工件管理工具

TL; DR：为什么使用Apache Archiva或Sonatype Nexus之类的东西作为工件存储库而不是Subversion？

我目前使用的构建系统有很多二进制Blob（图像，声音文件，已编译的二进制文件等），既可作为构建的输入也可作为输出。我们用于管理这些文件的系统非常临时；有些代码和代码一起被检入到Subversion存储库中，有些代码则存储在任何正式版本控制之外的其他位置。

我正在考虑将其合并，因此我们拥有一些更加自洽和易于使用的功能，并将二进制工件与代码分开。

Google告诉我，有一些可用的工件存储库（Archiva，Nexus， Artifactory …），但是从阅读的内容来看，与Subversion相比，使用它们没有任何优势。这将为我们照顾二进制文件-对于某些二进制文件已经做到了，我们只想重新排列存储库布局以将它们与代码分开-并具有明显的优势，因为我们已经拥有Subversion服务器和专业知识。

所以。与使用像Subversion这样的通用版本控制工具相比，使用专用的工件管理系统有什么优势？

简短的答案：通常，您不需要二进制工件和这些工件的更改的历史记录，只需要特定的版本即可。

更长的答案：每次对二进制文件进行少量更改时，版本控制系统都无法创建增量（两个文件之间的差异），因此它将创建一个全新的副本。

在像SVN这样的CVCS中，这并不是什么大麻烦，因为您只有存储库的一个中央副本-本地副本只有一个版本。（尽管，即使那样，您的存储库也可能变得非常大，使签入速度变慢。）但是，如果您以后切换到DVCS，则该存储库的每个副本都具有每个文件的完整历史记录，那会发生什么？更改的大小在那里变得非常相关。

它给您带来什么回报呢？它提供的唯一功能是能够返回到存储库的先前版本，并知道您具有该版本的正确二进制文件。

但是，您需要存储库中的整个二进制文件来执行此操作吗？还是仅仅拥有一个文本文件就可以告诉构建过程从其他位置的另一个存储库中提取哪个版本，您就能摆脱困境吗？

后者是工件库通常提供的。

此外，某些更专业的协议（例如Nexus）还将为您提供有关第三方工件许可的信息，这样您就不必冒被认为是FOSS库中某些细微条款的风险。

我们使用SVN作为发行版本的存储库，并且效果很好。我们在一个版本存储库中提供了优于30gb的各种版本构建，并且它在将构建拉出进行部署方面表现良好。

这样做的一些优点是..

• 添加到SVN中的二进制文件在平均节省空间上压缩了近60-70％。
• SVN充当发布的库（制造商），并且出于灾难恢复的目的备份了存储库。
• 通过https的SVN可以将发布代码安全地传递到DMZ中。