好的，所以我正在实现一个SVN存储库来跟踪Dot Net项目的开发。我已根据以下结构定义了存储库目录：
\project
\trunk
\branches
\systest
\production
\tags
\production_yyyymmdd
主要开发致力于项目的主干，并且基于来自客户端的变更请求（CR）执行开发。目前，我很乐意排除CR重叠的问题（即一个文件被CR更改了）。我的问题是如何管理仅将与单个CR相关联的文件更改从主干到系统以及从系统迁移到生产的过程。我现在所拥有的推广过程是（从系统迁移到prod为例）：
我遇到的问题是步骤3.如何告诉SVN要合并到迁移位置的文件。我不想要将所有更改从systest合并到prod（我甚至可能不希望将特定版本中的所有更改从systest合并到prod），只更改特定文件。
编辑：我还应该澄清所有存储库访问都是从Windows客户端完成的。我没有在SVN服务器上运行命令。 （为了感兴趣，SVN服务器在Linux上运行，但这对我认为的问题空间没有影响）
干杯
理查德
答案 0 :(得分：2)
这是我们使用的很酷的库/工具：Savana。对于每张票，开发人员将使用Savana创建一个分支，并在准备好时将此用户分支提升回主干。类似的方法可以解决您提出的问题：为任何给定任务创建分支，并在时机成熟时将其合并回主干路径。
答案 1 :(得分：0)
“正常”过程（即我的商店遵循的过程）是为产品的每个版本创建发布分支和标签副本。生产中发生的任何关键问题都在生产分支中修复，合并回主干，产品重新发布，并制作新的标签副本。
同时，针对主干开发了非关键问题，并将其定期发布。完成每个非关键问题（在您的案例中为CR）后重新发布不是标准做法。
如果您想在完成某个CR后重新发布，我认为您应该遵循功能分支的模式。当您收到需要生产版本的CR时，请从生产版本分支创建功能分支。完成更改后，将功能分支合并到生产分支和主干中，并从生产分支中释放。
您也可以考虑缩短发布周期。频繁发布可以减少对已发布代码进行更改的必要性。企业通常可以容忍等待6-8周才能实施变更，但不能等待6-8个月。
答案 2 :(得分：0)
就跟踪事物而言，我最简单的答案是强制执行某个开发人员规则 - 也就是说，每次提交只包含1个CR。
Tortoise support for the bugtraq properties可以通过确保每个提交评论至少包含一个CR编号来帮助您 - 这可能是一个有用的提示，告诉开发人员如果他们包含＆gt; 1跟踪编号然后他们可能做错了（除非一个修复确实做了多件事）。
因此，这将允许您使用您想要的CR从trunk到systemtest进行合并。您甚至可以使用togoise merge ui来查看trunk中的哪些修订版尚未合并到systemtest中。但是，当然现在你想要从系统测试到具有类似粒度的生产 - 这就是问题所在。
我认为问题在于系统测试中的单个修订可能包含多个中继提交，您可能还不希望它们全部用于生产。
我想知道从主干进行生产合并是否最好 - 而不是来自systemtest。理论上它应该是相同的代码 - 您将能够跟踪系统测试中的主干修订以及生产中的内容。
所以要明确这一点，你推动从trunk到systemtest的修订，测试它，然后如果没问题，将修订从trunk改为生产（你可能必须再次启动一个干净的生产分支）。
您应该能够编写一些使用mergeinfo的工具来确认哪些修订版本在systemtest中但哪些修订版尚未生产。并且使用bugtraq属性，您还应该能够告诉哪些CR完全合并到任一分支中，哪些CR还有更新。
如果您想要开始在测试和制作中推广少于完整的中继提交，那么您会遇到一些麻烦，尤其是在从同一个文件中选择更改时。您可以右键单击indiviudal文件并直接在文件级别合并（也许可以手动撤消某些更改），但选择文件和更改将是非常手动的工作，您将无法从工具中获得任何帮助。此外，您正在跟踪脚本开始变得非常复杂。
但请注意，通过这样做，系统测试和生产之间存在代码漂移的非常大的风险。我建议定期在分支机构之间进行差异，并确保您可以解决所有差异。如果两个分支具有从主干合并的相同修订，它们应该是相同的，任何差异应该是因为测试中的修订尚未生产，当然，不应该在生产中进行修订而不是在测试中。