Subversion - svn:externals 应该从哪里来？
我将在这里建立一条工作规则，即所有 svn:externals 引用都应来自另一个项目的标签，而不是来自其主干或任何分支。 这是一个合理的规则吗？或者您认为这种方法存在问题吗？ 我正在努力实现一个稳定的开发环境，我想知道这个规则是否会使开发变得更慢或更困难。
I am about to establish a rule at work here that all svn:externals references should come from the one of the other project's tag, never from its trunk or from any of its branches. Is this a reasonable rule or do you see problems / issues with this approach? I am trying to achieve a stable development environment and I wonder if this rule would make development slower or more difficult.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您担心的是，带有“svn:externals”的项目可以在没有对该项目进行任何提交的情况下进行更改。 这是一个问题，因为很难发现重大更改或回滚到一个好的版本。
所以，是的，要求 svn:external引用稳定是一个很好的规则。 只允许引用标签是实现这一目标的一种方法。 另一种方法是使用 -r 语法将外部固定到固定修订版。 示例来自 Subversion 书籍：
这也将保护你反对改变标签，这是一种比我喜欢的更常见的糟糕做法。
话虽如此，稳定性和持续集成之间仍然需要权衡。 无论如何，您通常都需要对外部依赖项进行更改和错误修复。 在这种情况下，您希望 CI 服务器尽快通知您依赖项的某些更改破坏了您的项目，以便尽快修复问题。 大多数持续集成服务器都支持检查外部。
出于这个原因，我认为保持主干中的外部跟踪依赖项的主干 HEAD 是可以的（如果你有 CI 服务器）。 只需在标记和创建稳定的维护分支时将外部固定到固定修订版即可。
Your concern is that a project with "svn:externals" can change without any commits to that project. That's a problem because it's hard to discover the breaking change or to roll back to a good version.
So yes, demanding that svn:external references are stable is a good rule. Only allowing references to tags is one way to achieve that. Another way is to use the -r syntax to pin the external to a fixed revision. Example from the subversion book:
This will also protect you against changes in tags, a bad practice which is more common than I like.
That being said, there still is a trade-off between stability and continuous integration. Often you need the changes and bug-fixes in the external dependencies anyway. In that case you want to be notified by your CI server as quickly as possible that some change in the dependencies broke your project, so that the problem can be fixed ASAP. Most continuous integration servers have support for checking externals.
For this reason I think it's OK to keep the externals in trunk tracking the trunk HEAD of your dependencies (if you have a CI server). Just pin your externals to fixed revisions when tagging and when creating stable maintenance branches.
以及实际上允许外部因素的决定？ 确保你这样做是出于正确的理由。 通常最好简单地从原始位置签出，或者在多个位置签入依赖项。 我过去曾被外部参考所困扰。 如果你要分支，它们就会成为一个真正的问题，除非你在这样做时“冻结”外部。
但要回答您的问题，拥有一个放置和引用所有外部组件的特定位置非常有意义。 这意味着您可以控制该位置的内容，并且人们知道当他们将某些东西放在那里时，它将被用作外部，因此被很多项目所依赖。
And the decision to actually allow externals? Makes sure you're doing it for the right reasons. It is often better to simply checkout from the original place and or, checkin the dependencies in multiple places. I've been burnt by external references in the past. If you're going to branch they become a real problem unless you "freeze" the external when you do.
But to answer your question, it makes a lot of sense to have a specific location where all externals are placed and referenced. That means that you can control the content of that location and people know that when they put something there then it will be used as an external and thus depended on by a lot of projects.
我认为这取决于您的软件开发实践的成熟程度。 您有变更管理流程吗？ 自动构建和报告？ 等等。最安全的做法是链接到项目的标记构建（即 lib、dll、jar 等）。
如果外部项目每周发布一次并频繁修复错误，那么它既可能是有帮助的，也可能是一种阻碍。 我发现，如果没有良好的配置管理策略，链接到标签很容易错过关键更新。 而且，当您开始“升级”该依赖项时，可能会有很多小的更改加起来会产生大量的工作。
对于相对稳定的项目，这是一个好主意。 唯一的问题是，并非所有 IDE 都明确表示源目录是外部引用。 在这种情况下，开发人员可以非常轻松地签入对该标签的更改。 据我所知，Subversion 还没有实现“只读”，尽管我一直在使用旧版本。
I think it comes down to how mature your software development practices are. Do you have change-management processes? Automated builds and reporting? Etc. The safest thing to do is to link to a tagged-build of the project (i.e. lib's, dll's, jar's, etc).
If the external project has weekly releases with frequent bug fixes, it could be both helpful and a hinderance. I found that without a good configuration management policy, linking to tags make it easy to miss critical updates. And, by the time you get around to "upgrading" that dependency, there may be a lot of small changes that add up to a lot of work.
On relatively stable projects, this is a good idea. The only problem is that not all IDE's make it clear that a source directory is an external refernce. In that case, it becomes very easy for developers to check-in changes to that tag. From what I recall, Subversion hasn't implemented "read only" yet, though I've been using an older version.
这取决于您认为主干的稳定性。
然而，开发人员可以将其外部的工作副本切换到主干。 指向开发分支内的主干也很好。 在项目的第一个稳定版本发布之前指向主干可能是可以的。
我个人的看法是非常小心地对待 trunk，因为它对我来说具有特殊的意义 - 它是该项目的完整历史。 根据定义，任何被释放的东西都必须经过主干。 如果您可以更改主干，而无需针对更改记录修订（如果您指向主干的外部，则实际上会发生这种情况），那么您就失去了对何时发布该修订以及何时将该修订合并到项目中的控制。
当您从主干分支时，记住将所有引用更改为特定修订版可能是一项尝试。 Hudson 可以通过其标签支持让事情变得更加明显，但除此之外没有什么帮助。
指向 trunk 还可能导致“不可触及的库”问题。
说到 CI，没有理由不能对所有组件以及最终的集成项目进行 CI。 通过选择何时合并到最新的库中，您可以选择何时进行集成工作。
然而，如果有某种机制表明“您的项目正在使用过时的库，最新版本是 X”，那就太好了。 目前这是不可能的。
此外，如果您有嵌套的外部组件，那么从基础库通过 5 层引用推送更改直到到达主项目是一件痛苦的事情。
It depends how stable you consider trunk to be.
However, it's fine for a developer to switch the working copies of their externals to a trunk. It's also fine to point to trunk within a development branch. It may be ok to point to trunk before the first stable release of a project.
My personal take is to treat trunk very carefully as it has a special meaning to me - it's the complete history of the project. Anything that gets released must go through trunk, by definition. If you can change trunk without having a revision recorded against the change (which is effectively what happens if you point to an external to trunk), you've lost control over when you release that revision, and when you incorporate that revision into your project.
Remembering to change all your references to specific revisions when you branch from trunk can be a trial. Hudson can make things more visible with its tagging support, but little else helps.
Pointing to trunk can also lead to the "untouchable library" problem.
When it comes to CI, there's no reason why you can't do CI on all the components as well as the final integrated projects. By choosing when to merge in the latest library, you choose when you want to do the integration work.
However, it would be nice to have some mechanism which says "Your project is using an out of date library, the latest version is X". This is not possible at the moment.
Also, if you have nested externals, pushing a change from a base library through 5 layers of references until it reaches the main project is a pain.