我想在全球部署一个已编译的软件。
由于我已经有一个用于代码版本控制的subversion服务器，我打算使用SVN进行软件部署。但是，由于许多人使用apt-get进行软件部署，我希望看到使用SVN优于apt-get的优缺点。
答案 0 :(得分：3)
不要将已编译的代码签入Subversion！对于包（RPM或.deb）来说尤其如此。
我看到的是人们将他们的包存储在Subversion中，然后使用Web-SVN浏览器指定URL，或者执行 checkout 并将包放在他们的本地系统上。我不推荐这个。
原因很简单：编译的二进制文件占用了大量空间。我们的RPM包大小可能达到数百兆字节。每次将其提交到Subversion时，都会将存储库的大小增加几百兆字节。在几个版本之后，您的存储库中就会有数GB的二进制文件。
为了什么？你不能在Subversion中 diff 二进制文件。你不能看他们的历史，看到任何有用的东西。并且，二进制文件的保质期很短。在每月多次发布版本的情况下尤其如此。您最终会得到一个必须维护的臃肿的存储库，其中90％是无人关心的信息。
然而，人们这样做是因为它很方便。您向某人提供Subversion URL，他们可以下载它。很重要。如果你有一个专用的发布服务器，他们可以做同样的事情，而且会更快。并且，您可以删除任何人不再需要的旧版本，并节省数千兆字节的空间。
仅仅因为很多人做某事并不意味着你也应该这样做。很多人也做海洛因，我也不建议这样做。
你有像Jenkins这样的构建服务器吗？如果这样做，请将编译的包存储在那里。您可以删除较旧的软件包（Jenkins将为您执行此操作），并在源代码和软件包之间保持连接。
在我工作的一个地方，我们使用Promoted Build Plugin设置Jenkins。当我们发布时，我们将进入Jenkins构建，并提升它。促销会标记我们的源代码，锁定构建以防止Jenkins删除存档的包，并将包发送到我们的apt-get服务器。更好的是，我们会使用版本号标记构建。您可以进入Jenkins，找到已发布的版本，查看源代码，下载软件包，以及查看一个版本与下一个版本之间的所有更改。
我们的Subversion存储库仅包含源，用户可以使用实际的apt-get包服务器进行自动包更新。
答案 1 :(得分：0)
SVN包含源代码，而apt-get将负责产品的所有安装。通常在使用SVN时，您只能获得该软件的副本，并且需要自己手动安装。
希望这有帮助。