每当我从我们的 SVN 签出项目时,它们都不会构建。要么是因为他们正在访问 GAC 中我没有安装在我的开发机器中的旧库。或者因为他们指向随着时间的推移而发生变化的外部因素。或者他们只是没有在项目 bin 中包含所需的 dll。
我的问题是,始终确保项目始终成功构建是最佳实践吗?还是仅根据具体情况需要?
每当我从我们的 SVN 签出项目时,它们都不会构建。要么是因为他们正在访问 GAC 中我没有安装在我的开发机器中的旧库。或者因为他们指向随着时间的推移而发生变化的外部因素。或者他们只是没有在项目 bin 中包含所需的 dll。
我的问题是,始终确保项目始终成功构建是最佳实践吗?还是仅根据具体情况需要?
是的。
(我需要输入更多字符,但实际上也没有任何理由......检查源代码并运行单个命令应该构建您的项目是无可争议的最佳实践)
威廉珀塞尔提出了一些很好的观点。我真的相信答案很简单。然而,将 dll 签入到 svn 几乎和不得不寻找它们一样糟糕。当然会有关于工具链的假设——检查编译器或类似 glibc 的东西是不合适的,这些东西将由你机器上的包管理器处理。
详细说明 :
是可以做到的,而且可能有很大的价值。
这是一个非常主观的问题,所以有很多答案。然而,依赖跟踪和解决是包管理工具最好解决的问题。版本控制系统不是包管理工具,(在我看来)尝试使用它是一个巨大的错误。项目应该从 vcs 构建吗?是的,在满足所有依赖项的开发人员的盒子上。它应该在任意系统上从头开始构建吗?不,这就是发布 tarball 的用途。许多项目喜欢使用 VCS 作为主要的部署系统,这使问题变得混乱。应该使用 VCS 来跟踪软件的历史,而不是部署或解决依赖关系。所以,我相信答案是合格的“不”。
让我们稍微构图一下
是的,应该有一种方法来构建源代码,最好是从存储库本身的简单、维护良好的指令中获取;通常,INSTALL
或者README
在 repo 的顶层。需要一个人来确保它存在并且是最新的。
但是不,要求每个分支的每次签到都满足这个要求是不合理的。对于“生产”或“稳定”分支来说,这是一个很好的要求,而且,文档化的策略也是理想的。