设置SVN以最适合开发->；质量保证->；戳

如果已经有人问过，我很抱歉，但我无法找到针对这种情况的答案：

对于我们的web应用程序，我们有3个系统：开发、质量保证和生产。现在，第三方正在维护代码，但很快它就会掌握在我们手中。我们将为每个阶段提供单独的构建环境。此外，我们使用RAD进行代码开发，因此实际上有一个主要步骤，测试/沙箱

理想情况下，我们希望以某种方式隔离每个阶段的存储库，这样我们就可以从DEV签出，进行一些更改，在本地测试它们，然后将它们签回DEV。如果DEV上一切正常，我们将签入QA，依此类推

我们应该为每一个都有单独的存储库吗，或者这属于“分支”的范畴，我们应该为dev、QA和prod提供单独的分支。您是否也可以提供实现理想路线的最佳方法

如果还有其他问题，请告诉我

谢谢

---

Chris

您应该有一个可以在部署过程中签出或导出的存储库

我们也有类似的设置。开发人员签出本地工作副本并在其开发环境中进行开发。当我们准备好登台时，或者你们称之为QA时，我们会将svn导出到那个环境中（通常是head，但我们总是跟踪具体的修订）

在QA过程中，我们继续在开发中开发并部署到QA

最后，当我们准备好进行生产时，我们将正确的版本从存储库导出到生产环境中

很好

---

[编辑：就“这是分支”而言，您所描述的可能更像是跟踪修订。然而，分支是管理不同开发线的一项非常重要的技术。这不应该与每个阶段（开发、阶段、活动）都有不同的分支相混淆]使用分支和合并

我们做了以下工作：

发布时，我们创建一个当前发布分支。我们在两个版本之间进行bug修复，然后将它们合并回主干

---

我们在trunk上开发，当我们准备发布时，我们会创建一个QA分支。我们对它进行测试和修复，然后将其推出，它就成为我们当前的发行版分支。

如果您使用简单确认的任务进行单一的开发流，那么这很好。但随着多个开发流程的出现，以及任务被取消或延迟的可能性，这将证明更具挑战性。然后，在应用程序中需要某种时间依赖性。您还可以使用功能分支之类的东西，一旦构建了功能，这些分支就会合并回主干中。

我们有类似的模式。在SVN中，我们有三个分支，

trunk

，

prepod

和

PROD

。每当新功能准备好尝试时，它就会被合并到

prepod

分支（只使用特定的修订号，并且只针对特定的文件），如果它通过QA，它就会被提交并合并到

PROD

分支。当更改在

PROD

分支中提交时，它们将自动部署到所有生产服务器中。除了测试新功能外，

prepod

和

PROD

是相等的。

我们对每个错误修复、功能或任务都有一个开发分支，涉及的项目往往有多个子分支

最初，它是一种为一行代码修复创建新分支的wierd，但它允许将主干合并到分支中，然后进行回归测试，最后合并回主干中

理想情况下，这意味着任何合并到主干中的东西都不会破坏构建，这意味着您不必害怕提交代码来创建脆弱的构建

我经常为一个问题使用多个分支，测试不同的解决方案，同时仍然可以从SCM中获益

我们还标记特定的版本或发布，允许基于已知良好代码的快速部署

---

我们的许多基于web的系统都使用svn:external，它指向依赖项的特定版本，如库和供应商代码。部署是从外部进行的，而不是直接签出或导出。

trunk是否反映产品？否，trunk可以具有从未合并到预发布中的功能