让开发人员使用 SVN 处理上次成功的构建
如果您使用 subversion，您如何组织开发人员可以轻松地检查最后一个工作版本并在这个版本上工作，而不是在可能损坏的 HEAD 上工作？
问题背后的想法如下。当许多开发人员同时处理一个项目时，可能会发生有人破坏构建或某些测试的情况。持续集成有助于及早发现这些东西，但并不能防止HEAD发布暂时被破坏。因此，我想让每个人都能够轻松查看并处理已知有效的最新版本，并且仅在需要提交时才更新到 HEAD。使用 SVN 创建标签似乎不是执行此操作的适当方法，因为在 SVN 中，标签本质上是一个新分支，并且在每次成功构建后很难移动。你会怎么做？
If you work with subversion, how can you organize that developers can easily checkout the last working build and work on this one, instead of working on a potentially broken HEAD?
The idea behind the question is as follows. When a lot of developers work simultaneously on a project, it can happen that someone breaks the build or some tests. Continuous integration helps to find these things early, but it does not prevent that the HEAD release is temporarily broken. So I want to give everyone the ability to easily check out and work on the latest revision known to be working, and only update to HEAD when necessary for a commit. Creating a tag with SVN seems not to be the appropriate way to do this, since in SVN a tag is essentialy a new branch and can hardle be moved after each successful build. How would you do this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
如果您的开发人员遵循“更新头部，运行本地构建/测试，签入”的标准实践，那么您的服务器构建损坏的可能性应该很小......
也就是说，您可以更新您的构建成功时的公共批处理文件/脚本，由您的开发人员使用，并签出主干的特定修订版（您的成功构建所针对的修订版）。因此，在成功构建后，您将 checkout 命令更新为如下所示：
其中
RevisionNumber，要么在服务器 checkout 运行时存储，要么通过调用svn info派生，并且提取Revision:值If your developers are following a standard practice of 'update to head, run local build/tests, checkin', then the chances of you having a broken server build should be quite slim...
That said, you could get your build to update a public batchfile/script on success, which is used by your developers and does a checkout to a particular revision of the trunk (the revision that your successful build was run against). So on successful build you'd update the checkout command to be something like:
Where
RevisionNumber, was either stored when the server checkout was run, or derived by callingsvn infoand extracting theRevision:value如果您的 CI 服务器通知所有开发人员，即不仅仅是那些在构建中断时破坏构建的开发人员，那么您的开发人员可以通过监视失败的构建电子邮件并推迟到“构建已修复”电子邮件发出来避免获取损坏的头。如果开发人员迫切需要更新（也许在假期之后），他们可以返回到上一个良好的修订版本。大多数 CI 软件都支持这一点。我知道詹金斯提供了一个“最后一次成功构建”链接。如果您想要一个网页来显示此内容，就像 @forsvarir 建议的那样，您可以轻松地抓取此页面。
If your CI server notifies all developers, i.e. not just those who broke the build when a build breaks, your developers can avoid fetching a broken head by watching for a failed build email and holding off until the 'build fixed' email goes out. If a developer crucially needs to update (perhaps after a vacation), they can go back to the last good revision. Most CI software supports this. I know for a fact Jenkins provides a 'last successful build' link. If you wanted a web page to show this, like @forsvarir suggested, you could easily scrape this page.
从纯技术角度来看，问题在于您试图根据持续集成环境中的构建结果来编排源代码控制的行为，这有点从后到前。我不知道有什么方法可以让开发人员根据 CI 构建结果从同一路径中的早期版本中提取出来。
但实际上，这是一个开发实践问题。开发人员不应该提交“破坏构建”的代码，并且已经写了很多关于应该对那些这样做的人进行惩罚的文章:)
但是，当然，本地构建可以成功，而将代码构建集成回后备箱可能会出现故障。这就是为什么像 TeamCity 这样的产品具有“个人构建”的概念，即可以针对主干构建正在进行的工作，并且只有在成功构建后才进行提交。
简而言之，您的问题是已知和公认的，并且存在解决此问题的工具和实践组合。但这些做法不包括禁止基于构建结果拉取代码。
The problem from a pure technical perspective is that you're trying to orchestrate the behaviour of source control based on the outcome of a build in the continuous integration environment which is a bit back to front. I'm not aware of any way to cause developers to pull from an earlier revision within the same path depending on a CI build outcome.
But really, this is a development practice issue. Developers shouldn't be committing code which "breaks the build" and much has been written on the sort of punishments which should be dished out to those who do :)
But of course a local build can succeed whilst a build from code integrated back into the trunk can fail. This is why products like TeamCity have the concept of a "personal build" whereby work in progress can be built against the trunk and only committed after it builds successfully.
So in short, your problem is known and recognised and a combination of tools and practices exist to address this. But the practices don't include prohibiting pulls of code based on build outcomes.
即使我使用 SVN，由于它允许许多开发人员多次签出，因此无论谁签入文件，都需要检查并与以前的版本进行正确比较。
假设在下一个版本中，如果代码损坏，我们可以轻松地将其恢复回来。
Even I work with SVN, Since it allows mulitple checkout from many developers, Whoever checks in the file, need to check and compare it properly with the previous versions.
Suppose in the next build if the code breaks, we can easily revert it back..
如果这确实是一个例外，那么最简单的方法可能是建议开发人员在 CI 服务器网页中找到最后一次成功构建/部署的修订号，并建议在出现问题时返回到该修订号。这样问题就可以得到解决，而不会过多地打扰其他人。
If this is really an exception it is perhaps easiest to advise the developers where the revision number of the last successful build / deployment is found in the CI server webpages, and suggest to go back to this revision number in case of trouble. Then the problem can be fixed without disturbing the others too much.