【发布时间】：2013-10-29 15:20:14
【问题描述】：
每当我从我们的 SVN 签出项目时，它们都不会构建。 要么是因为他们正在访问 GAC 中我没有安装在我的开发机器中的旧库。 或者因为他们已经指向随着时间的推移而发生变化的外部因素。 或者他们只是没有在项目 bin 中包含所需的 dll。
我的问题是，始终确保项目始终成功构建是最佳实践吗？还是仅根据具体情况需要？
【问题讨论】：
标签： svn
【发布时间】：2013-10-29 15:20:14
【问题描述】：
是的。
（我需要输入更多字符，但实际上也没有任何理由......毫无疑问的最佳实践是检查源代码并运行单个命令来构建您的项目）
William Pursell 提出了一些出色的观点。我真的相信答案很简单。然而，将 dll 签入到 svn 几乎和不得不寻找它们一样糟糕。 当然会有关于工具链的假设 - 不适合签入编译器或将由您机器上的包管理器处理的 glibc 之类的东西。
详细说明：
- 新的团队成员应该能够按照文档了解如何安装所需工具，查看源代码并运行构建。
- 通过将二进制文件（dll 或 jars）签入 svn 来获得第一名将导致糟糕的时刻。
- 如何获得这些所需的库取决于平台和工具链。这完全是 java（maven 和 ant/ivy）中已解决的问题，并且 .NET 对 nuget 有很好的支持。我使用过混合使用这些工具的系统，这些工具甚至可以与老派 c++ 一起使用，以获得像 boost 这样的库。重要的一点是，存在某种与描述这些依赖关系以及如何解决它们的源一起签入的清单。
可以做到，可能有很大的价值。
【讨论】：
-
那么如果项目有依赖，那么该依赖的所有源代码都应该在存储库中吗？那么glibc、ncurses、python等的源码一定要在repository里吗？我真的不明白这个立场。在每个存储库中包含所有依赖项是荒谬的，而且这样做当然不是最佳实践，但我不断看到人们争论这个立场。这些对我来说似乎不相容。
-
我从未提及将任何依赖项放入源存储库中。签入任何二进制文件是一个非常糟糕的主意，尤其是对于 DVCS 系统（git、hg 等）。当然，在构建之前必须安装一些预期的工具（编译器或解释器。）。任何需要的库都应该使用依赖管理器（maven、ivy、nuget 等）获取。
这是一个非常主观的问题，所以有很多答案。但是，依赖项跟踪和解决是包管理工具最好解决的问题。版本控制系统不是包管理工具，（在我看来）尝试使用它是一个巨大的错误。项目应该从 vcs 构建吗？是的，在满足所有依赖项的开发人员的盒子上。它应该在任意系统上从头开始构建吗？不，这就是发布 tarball 的用途。许多项目喜欢使用 VCS 作为主要的部署系统，这使问题变得混乱。应该使用 VCS 来跟踪软件的历史，而不是部署或解决依赖关系。所以，我相信答案是合格的“不”。
【讨论】：
让我们稍微框架一下
是的，应该有一种方法来获取要构建的源代码，最好是从存储库本身内的简单、维护良好的指令中获取；通常，INSTALL 或 README 在 repo 的顶层。需要有人来确保它存在并且是最新的。
但是不，要求每个分店的每次签到都满足这个要求是不合理的。对于“生产”或“稳定”分支来说，这是一个很好的要求，而且，记录在案的策略也是理想的。
【讨论】：