2

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

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

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

  1. 根据当前生产分支创建标签“production_yyyymmdd”（如果您愿意，这用于检索特定的“版本”）
  2. 从生产“更新”到本地“迁移”位置（例如 C:\Build\ProjectName）
  3. “合并”从“系统测试”到本地“迁移”位置的选定更改
  4. “提交”更改回生产

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

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

干杯
理查德

4

3 回答 3

2

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

于 2009-07-02T02:31:01.947 回答
0

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

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

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

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

于 2009-07-02T03:20:09.400 回答
0

哇，这实际上听起来像是您在这里获得的一个不错的健全的晋升系统:)

在跟踪事物方面，我最简单的答案是强制执行一定的开发人员纪律——也就是说，每次提交只包含 1 个 CR。

Tortoise支持 bugtraq 属性，这可以通过确保每个提交评论至少包含一个 CR 号来帮助您——这可能是一个有用的提示，可以告诉开发人员如果他们为提交包含 >1 个跟踪号，那么他们重新可能做错了（除非一个修复确实做多件事）。

因此，这将使您仅使用所需的 CR 从主干合并到系统测试。你甚至可以使用乌龟合并用户界面来查看主干中的哪些修订尚未合并到系统测试中。但是当然，现在您将希望以相似的粒度从系统测试转到生产 - 这就是问题所在。

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

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

所以要明确一点，您将修订版从主干提升到系统测试，对其进行测试，然后如果没问题，将修订版从主干提升到生产（您可能必须再次启动一个干净的生产分支）。

您应该能够编写一些使用 mergeinfo 的工具来为您确认哪些修订在 systemtest 中，但哪些不在生产中。并且使用 bugtraq 属性，您还应该能够分辨出哪些 CR 已完全合并到任一分支中，哪些还有待修改。

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

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

于 2009-07-02T07:52:37.153 回答