我们的开发团队（约40位开发人员）每两周进行一次正式构建。我们有一个过程，在“构建日”中，每个开发人员都禁止将代码提交到SVN中。我不认为这是一个好主意，因为：禁止开发人员因提交每周版本而提交代码
我想知道你的团队是否有相同的政策，如果不是你如何处理这种情况。
谢谢
通常情况下，构建是从一个带标签的代码。
如果标签被定义（并且不移动），每个开发人员都可以提交尽可能多的内容：构建将从固定和定义的代码集继续进行。
如果需要修改该组代码，则可以从该标签定义一个分支，在合并回当前的开发分支之前，可以进行小修补以实现正确的构建。
“开发工作”（像调整版本）不应该阻止另一项开发工作（日常提交）。
问题是：如果我们基于修订版本构建，但后来我们发现BVT失败了，那么某些开发人员将修复此问题并根据最新代码重新构建构建版本，但同时其他开发人员可能会编写代码（如果没有政策），并且该代码可能会导致更多问题导致BVT失败。 – xeranic 2010-03-11 05:28:54
有许多版本控制系统可以让你为旧版本打补丁并向前应用（mercurial和git做到这一点）。只要该修复程序在一致的修订版上得到验证，就没有理由不适用了。 – tzenes 2010-03-11 05:31:44
@Xinwang：然后你可以有一个“构建”分支，并将特定修订合并到构建分支中，然后将该分支用于构建过程。 – 2010-03-11 05:32:13
听起来令人沮丧。你们有没有理由Continuous Integration？
如果这听起来太极端了，那么肯定会投入一些时间来学习SVN中的分支工作方式。我认为你可以说服团队在分支上开发并合并为主干，否则将“正式构建”提交给特定的标记/分支。
我曾参与过类似政策的项目。我们需要这样的政策的原因是我们没有使用分支机构。如果开发者被允许创建一个分支，那么他们可以在该分支上做任何他们需要的提交，而不会打断其他任何人 - 在每周构建期间，策略变成“不合并到主”。
另一种方法是让周为构建分裂出去到一个分支，这样不管什么得到的检查（以及可能的合并），每周的版本将不会受到影响。
正如VonC所建议的那样使用标签也是一种好方法。但是，您需要考虑标记文件需要夜间构建补丁时会发生什么情况 - 如果开发人员在标记后检查了该文件的更改，并且该开发人员的更改不应包含在每周构建中？在这种情况下，无论如何你都需要一个分支。但分支标签也是一个好方法。
我也参与过让分支像疯子一样的项目，它试图弄清楚任何特定文件正在发生什么。更改可能会在同一时间段内提交给多个分支机构。最终需要解决合并冲突。这可能是一件非常头疼的事情。无论如何，我的偏好是能够使用分支机构。
对于使用分支机构+1;）但是你是对的，需要定义并遵循分支策略，以避免合并工作流恶梦（http://stackoverflow.com/questions/216212#216228）。 – VonC 2010-03-11 06:34:55
我们为每张票或新功能创建分支，即使票证很小（例如，只需要2个小时即可修复）。
在每次迭代的每个编码部分的末尾，我们决定在下一个版本中包含哪些票据。然后，我们将这些票券合并到主干中并发布软件。
该过程中还有其他步骤，其中在将票证合并到中继线之前，由其他开发人员在每个故障单分支上执行测试。
开发人员可以随时通过从主干创建自己的分支进行编码。请注意，我们是一个只有12名开发人员的小团队。
如果修补程序相对独立，并且合并合并很容易进行，则可以很好地工作。 +1。这种方法唯一的问题是，每个分支涉及创建一个复杂的执行和测试环境（重置测试数据库，部署在特殊的测试Web服务器上......），这需要花费时间。在这种情况下，“每个小任务的一个分支”吸引力就会小得多。 – VonC 2010-03-11 06:38:50
凯文和VonC都很好地指出，构建应该从代码的特定版本开始，并且不应该阻止开发人员提交新代码。如果这在某种程度上是一个问题，那么你应该考虑使用另一个版本管理软件，它使用集中的AND本地存储库。例如，在mercurial中，像svn一样有一个中央存储库，但开发人员也有一个本地存储库。这意味着当开发人员进行提交时，他只会向其本地存储库提交，并且其他开发人员不会看到这些更改。一旦他准备为其他开发人员提交代码，那么开发人员只需将他的本地存储库中的更改推送到集中式存储库。
这种方法的优点是开发人员可以提交更小的代码段，即使它会破坏构建，因为更改只适用于本地存储库。一旦变化足够稳定，就可以将它们推送到集中式存储库。通过这种方式，即使集中式存储库已关闭，开发人员也可以拥有源代码管理的优势。
哦，你会以全新的方式看待分支。
如果你发生了兴趣多变，看看这个网站：http://hginit.com
DVCS模型中并不完全存在“中央存储库”（除非您选择将其作为中央存储库）。请参阅http://stackoverflow.com/questions/995636/popularity-of-git-mercurial-bazaar-vs- which -to-recommend/995799＃995799。+1尽管如此，本地提交方法 – VonC 2010-03-11 06:32:34
步骤1：svn的副本/主干/你/项目/云/这里/温度/建造
第2步：按摩你的源代码in/temp/build
第3步：执行build/temp/build。如果遇到错误，修复它们在/温度/建立和重新建造
第4步：如果成功，SVN移动/温度/构建/建造/产品/ buildnumber
这样，开发人员可以检查时，他们想要并且不受日常/每周/每月/每年构建的干扰
SVN的一个很好的配方。+1 – VonC 2010-03-11 06:25:14
哇，这是一种可怕的开发方式。
上次我在一个非常庞大的团队工作，我们在3个时区中有大约100个开发人员：美国，英国，印度，所以我们可以有效地进行24小时开发。
每个开发人员都会检查构建树并研究他们必须处理的内容。与此同时，会有连续的构建发生。构建将从提交的代码中复制并构建它。任何失败都会返回到最新的提交者（代码）。
结果：
大多数开发者有两台机器，使他们能够在第二个bug工作，而在另一台机器上运行他们的测试（测试是非常图形，并会引发各种焦点问题，让您真正需要不同的机器做其他工作）。
高生产力，持续发展，没有死亡时间，如你的情况。
公平地说，我认为我不能在你描述的位置工作。以这种非生产性的方式工作会毁灭灵魂。
我坚信您的组织可以从持续集成中受益，而持续集成可以在您经常构建的情况下为您的代码库进行签入。
不知道我是否会因为这样说而被枪杀，但你应该真的转向像GIT这样的分散式解决方案。 SVN对此很恐怖，而你无法承诺的事实基本上阻止了人们正常工作。在40人这是值得的，因为每个人都可以继续自己的工作，只推动他们想要的东西。构建服务器可以在不影响每个人的情况下完成自己想要的任务。
另一个例子，为什么莱纳斯说的几乎所有情况下，像git这样的分散式解决方案在现实生活中最适合。
这个政策确实看起来有限制和任意...为什么不创建一个构建分支并让开发人员继续检查树干呢？或者让开发人员在构建日期间如何分支自己的代码？ – 2010-03-11 05:19:19
每年构建一次，那样问题发生的频率更低;-) – mjv 2010-03-11 05:19:33
问题是：如果我们基于修订版本构建，但后来发现BVT失败，则某些开发人员将修复此问题并根据最新版本重新构建构建代码，但同时其他开发人员可能会编写代码（如果没有该策略），并且该代码可能会导致更多问题导致BVT失败。 – xeranic 2010-03-11 05:28:33