目前在我们的企业中，我认为这种情况并不常见，或者至少我没有在互联网上找到类似的情况。我的问题是我们的软件可以通过多个要求发展，并且两者都不一定会在发布日期重合。
我们有一个开发周期，所有软件都是在“DEV”环境中开发的，然后它被处理到SQA，因此可以在“LAB”环境中进行测试;如果一切正常，则将该软件移至“PROD”环境。我在这里遇到的问题是，我不能使用单个主干，我也看不到单个分支如何工作。
例如，假设我有要求A和B，一个要在今天发布，另一个要从今天开始。两者都已达到LAB环境，但今天发布到PROD环境只需要包含A，因为我们的业务用户尚不需要B（并且它不能提前发布，因为它会向其他系统引入一些错误）。这两个要求都是在不同的分支机构中开发的（它们满足不同的需求）在这种情况下，我的问题是，我不能有一个单独的主干，开发人员可以合并在“DEV”环境中查看两个更改，然后使用相同的主干来提供“LAB”环境，因为它的源代码尚未安排发布。
我想我还应该提一下，为每个分支都有一个单独的开发环境是不可能的，因为这个软件基于PL / SQL（Oracle），而我们当前的测试数据库大小约为350Mb，因此有一个不同的每项要求都相当昂贵且难以管理。
任何建议或类似经历都将受到赞赏。
此致
答案 0 :(得分：3)
我建议遵循：
开发人员开始针对相应功能分支开发新需求。然后重新集成已经决定包含在环境LAB / pre-lab /中的功能分支，您可以在其中集成来自trunk /的新功能和错误修正的更改。
只要您知道可行（将需要一些时间，因为任何集成步骤从多个来源合并），您将合并从pre-lab /到lab /的所有更改。当您限制自己仅从pre-lab /到lab /进行合并时，此合并将始终是干净的，即只需单击鼠标即可。
在trunk /中，您可以将所有功能分支和错误修复合并在一起，但根据您的项目结构和软件开发过程，这可能需要进一步讨论。
一定要使用Subversion 1.5，因为这种合并会让你在旧版本中迷失方向。
答案 1 :(得分：2)
根据你的最后一段，你有很多泡菜。我认为最好的做法是分支每个功能，并在需要/释放时将功能合并到主干中。我真的不知道是否有第二种改善你情况的最佳做法（但我不那么聪明）......
答案 2 :(得分：0)
听起来我觉得你可以从使用分布式VCS（git，mercurial，bazaar等）中受益。
答案 3 :(得分：0)
在大多数情况下，您需要的是在启用和禁用功能的情况下测试生成的应用程序，以便您可以选择在发布时启用或禁用的内容。
重点是，如果您创建一个包含两者的测试版本，然后去完全删除一个部分，无论您的版本控制系统如何，您最终都可能会产生一个集成问题，您不会知道这个问题而且您将拥有已将其推送到生产服务器。
无论您做什么，您仍需要测试您将给予客户的确切产品。
然后应该发布一个版本，而不是将要生产的版本。将要生产的是经过测试的版本。此时，它只是为每个版本或功能创建分支并合并所需内容的问题。
合并操作不一定适用于所有事情。如果提交完成，您应该能够轻松地合并分支之间所需的功能（命令和/或文件）。另请注意，SVN只能保留自1.5 /
以来合并分支的历史记录