SVN促进测试和生产的变化

好的，我正在实现一个SVN存储库来跟踪一个.Net项目的开发。我已经按照以下结构定义了存储库目录：

\project  
   \trunk  
   \branches  
      \systest  
      \production
   \tags  
      \production_yyyymmdd

主要开发致力于项目主干，并根据客户的变更请求（CRs）进行开发。目前，我很高兴排除了CRs重叠的问题（即文件的更改量超过CR）。我的问题是如何管理仅将与单个CR相关的文件更改从主干迁移到systest以及从systest迁移到生产的过程。目前的升级过程是（以从systest迁移到prod为例）：

基于当前生产分支创建标记“production_yyyymmdd”（如果愿意，可用于检索特定的“版本”）

从生产“更新”到本地“迁移”位置（例如C:\Build\ProjectName）

将选定的更改从“systest”位置“合并”到本地“迁移”位置

将更改“提交”回生产环境

我的问题是步骤3。如何告诉SVN哪些文件要合并到迁移位置。我不想将所有更改从systest合并到prod（我甚至可能不想将某个特定版本中的所有更改从systest合并到prod），只想合并特定文件中的更改

编辑：我还应该澄清，所有存储库访问都是从Windows客户端完成的。我没有在SVN服务器上运行命令。（出于兴趣，SVN服务器运行在Linux上，但我认为这与问题空间没有任何区别）

干杯

---

Richard

我们使用了一个很酷的库/工具：。对于每个票据，开发人员将使用Savana创建一个分支，并在准备就绪时将该用户分支提升回主干。类似的方法可以解决您提出的问题：您为任何给定的任务创建一个分支，并在适当的时候将其合并回主主干路径。

正常的过程（即我的商店遵循的过程）是为产品的每个发布创建一个发布分支和一个标记副本。生产中出现的任何关键问题都在生产分支中修复，并合并回主干，重新发布产品，并制作新的标签副本

同时，针对主干开发非关键问题，并将其汇总为定期发布。在完成每个非关键问题（您的情况下为CR）后重新发布不是标准做法

如果您想在完成某个CR后重新发布，我认为您应该遵循特性分支的模式。当您收到需要生产版本的CR时，请从生产版本分支创建特征分支。更改完成后，将要素分支合并到生产分支和主干中，并从生产分支发布

---

<>你也可以考虑缩短你的发布周期。频繁的发布减少了对已发布代码进行更改的必要性。企业通常可以容忍等待6-8周来实施变更，但不能容忍等待6-8个月。

哇，这听起来像是一个不错的明智的促销系统：）

在跟踪方面，我得到的最简单的答案是强制执行某个开发人员规程——即每次提交只包含1个CR

Ottoise提供了一个帮助，它可以确保每个提交评论至少包含一个CR编号——这可能是一个有用的提示，告诉开发人员，如果提交的跟踪编号大于1，那么他们可能做错了（除非一个修复确实做了多件事）

所以，这将允许您从主干合并到systemtest，只需使用您想要的CR即可。您甚至可以使用tortoise合并ui查看trunk中哪些修订尚未合并到systemtest中。但当然，现在您需要从SystemSt转到粒度类似的生产—这就是问题所在

我看到的问题是，systemtest中的一个修订版可能包含多个主干提交，您可能还不希望它们全部投入生产

我想知道是否最好从主干将合并到生产中，而不是从systemtest进行合并。理论上，它应该是相同的代码-您将能够跟踪系统测试中的主干修订和生产中的修订

因此，为了明确这一点，您将修订版从主干升级到systemtest，对其进行测试，然后如果可以，将修订版从主干升级到生产（您可能需要再次启动清洁生产分支）

您应该能够编写一些使用mergeinfo的工具来确认哪些修订在systemtest中，而哪些不在生产中。使用bugtraq属性，您还应该能够判断哪些CR完全合并到任一分支中，哪些还有修订

如果您想要开始将不到一个完整的主干提交提升到测试和生产中，那么您会遇到一些麻烦，尤其是从同一个文件中选择更改时。您可以右键单击单个文件并直接在文件级别合并（或者手动撤消某些更改），但选择文件和更改将是非常手工的工作，您不会从工具中获得任何帮助。此外，您正在跟踪的脚本开始变得非常复杂

---

但是，请注意，这样做确实存在代码在系统测试和生产之间漂移的风险。我建议定期在分支机构之间进行差异分析，并确保您能够解释所有差异。如果这两个分支具有从主干合并的相同修订，那么它们应该是相同的，任何差异都应该是因为测试中的修订尚未投入生产，当然，生产中不应该有未投入测试的修订。

我假设您的主干是