在开发过程中是否应该修复外部依赖关系？
我和我的团队正在开发几个项目，这些项目共同依赖于一些通用库。这些公共库当前使用 svn:externals 与项目一起检出。
问题是，项目的主干应该跟踪每个库的 HEAD，还是链接到特定的修订版本？
问题库是由公司中的其他人非常积极开发的，偶尔会进行检查，从而破坏依赖于库的项目。即使我们自己没有更改任何内容，这也会在我们的 CI 上显示为红色斑点。有些人认为，“这就是我们拥有 CI 服务器的原因；以便我们知道何时落后”，而另一些人则认为，“我们希望了解所有更改如何在前沿。”
有人可以评论最佳实践吗？我有我的看法，暂时保留。
My team and I are working on several projects that collectively depend on some common libraries. These common libraries are currently checked out together with the projects, using svn:externals.
The question is, should the projects' trunks track the HEAD of each library, or be linked to specific revisions?
The issue libraries are very actively developed by others in the company, and occasionally checkins are made that break the projects depending on a library. This shows up as a red blob on our CI, even if we haven't changed anything ourselves. Some people argue that, "that's why we have a CI server; so that we know when we're falling behind," where others argue, "we want to see how all the changes integrate, on the bleeding edge."
Can anyone comment on the best practice? I have my opinion, which I will reserve for now.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果外部依赖项足够稳定以创建版本，那么是的，您应该有一个特定的修订版，而不是指向每个库的主干。另一方面，如果您所有的开发都是“前沿”，正如您提到的，那么在某些情况下，事情会变得不同步或根本无法编译，这只是生活的事实。
If the external dependencies are stable enough to create a release, then yes, you should have a specific revision instead of pointing to the trunk of each library. On the other hand, if all of your development is "bleeding edge" as you mention, then there will be cases when things will become out of sync or simply not compile and that is just a fact of life.