SVN 促进测试和生产的变革
好的，我正在实现一个 SVN 存储库来跟踪 Dot Net 项目的开发。 我按照以下结构定义了存储库目录：
\project
\trunk
\branches
\systest
\production
\tags
\production_yyyymmdd
主要开发致力于项目的主干，并根据来自客户端的更改请求（CR）进行开发。 目前，我很高兴排除了重叠 CR 的问题（即文件的更改次数超过了 CR 的更改次数）。 我的问题是如何管理仅将与单个 CR 相关的文件更改从主干迁移到系统测试以及从系统测试迁移到生产的过程。 我目前的升级过程是（以从 systest 迁移到 prod 为例）：
- 根据当前生产分支创建一个标签“product_yyyymmdd”（如果您愿意，这用于允许检索特定的“版本”） )
- 从生产环境“更新”到本地“迁移”位置（例如 C:\Build\ProjectName）
- “合并”选定从“systest”更改为本地“迁移”位置
- “提交”更改回 我遇到
的问题是第 3 步。如何告诉 SVN 将哪些文件合并到迁移位置。 我不想想要合并从 systest 到 prod 的所有更改（我什至可能不想合并从 systest 到 prod 的特定修订版中的所有更改），只合并特定文件中的更改。
编辑：我还应该澄清，所有存储库访问都是从 Windows 客户端完成的。 我没有在 SVN 服务器上运行命令。 （出于兴趣，SVN 服务器在 Linux 上运行，但这对问题空间没有影响，我相信）
干杯
理查德
OK, so I am implementing an SVN repository to track development on a Dot Net project. I have defined the repository directory in accordance with the following structure:
\project
\trunk
\branches
\systest
\production
\tags
\production_yyyymmdd
Main development is committed to the trunk of the project, and development is performed based on Change Requests (CRs) from the client. For the moment, I am happy to exclude the problem of overlapping CRs (ie a file that is changed by more than on CR). My problem is how to manage the process of migrating only the file changes associated with a single CR from trunk to systest and from systest to production. The promotion process as I have it at the moment is (take migrating from systest to prod as an example):
- Create a tag "production_yyyymmdd" based on the current production branch (this is used to allow retrieving a particular 'version' if you like)
- "Update" from production to a local "Migration" location (eg C:\Build\ProjectName)
- "Merge" selected changes from "systest" to local "Migration" location
- "Commit" changes back to production
The problem I have is with step 3. How do I tell SVN which files to merge to the Migration location. I do not want to merge all changes from systest to prod (and I might not even want to merge all changes in a particular revision from systest to prod), only changes in specific files.
Edit: I should also clarify that all the repository access is being done from a Windows client. I'm not running commands on the SVN server. (For interest's sake, the SVN server is running on Linux, but that makes no difference to the problem space I believe)
Cheers
Richard
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
“正常”流程（即我的商店遵循的流程）是为产品的每个版本创建一个发布分支和一个标签副本。 生产中发生的任何关键问题都会在生产分支中修复，合并回主干，重新发布产品，并制作新的标签副本。
同时，针对主干开发非关键问题并汇总到定期版本中。 在完成每个非关键问题（在您的情况下为 CR）后重新发布并不是标准做法。
如果你想在某个 CR 完成后重新发布，我认为你应该遵循功能分支的模式。 当您收到需要生产版本的 CR 时，请从生产版本分支创建一个功能分支。 更改完成后，将功能分支合并到生产分支和主干，并从生产分支发布。
您还可以考虑缩短发布周期。 频繁的发布减少了对已发布代码进行更改的必要性。 企业通常可以容忍等待 6-8 周才能实施变更，但不能容忍 6-8 个月。
The "normal" process (i.e. the one my shop follows) is to create a release branch and a tag copy for each release of the product. Any critical issues that occur in production are fixed in the production branch, merged back into the trunk, the product is re-released, and a new tag copy is made.
Meanwhile, non-critical issues are developed against the trunk and rolled up into a periodic release. It is not a standard practice to re-release upon completion of each non-critical issue (CR in your case).
If you want to re-release upon completion of a certain CR, I think you should follow the pattern of feature branching. When you receive a CR that requires a production release, create a feature branch from the production release branch. When the changes are completed, merge the feature branch into the production branch and the trunk and release from the production branch.
You might also consider shortening your release cycle. Frequent releases mitigate the necessity to make changes to released code. The business can often tolerate waiting 6-8 weeks for a change to be implemented but not 6-8 months.
哇，这实际上听起来像是一个很好的理智的晋升系统:)
在跟踪事物方面，我最简单的答案是强制执行特定的开发人员纪律 - 也就是说，每次提交仅包含 1 个 CR。
Tortoise 支持 bugtraq 属性，可以在这里为您提供帮助通过确保每个提交评论至少包含一个 CR 编号 - 这可能是一个有用的提示，告诉开发人员如果他们在提交中包含 > 1 个跟踪编号，那么他们可能做错了（除非有一个修复确实如此）做多项事情）。
因此，这将让您从主干合并到系统测试，只需使用您想要的 CR。 您甚至可以使用 tortoise merge ui 来查看 trunk 中的哪些修订尚未合并到 systemtest 中。 但当然，现在您会希望以类似的粒度从系统测试转到生产 - 这就是问题所在。
我看到的问题是 systemtest 中的单个修订可能包含多个主干提交，并且您可能不希望它们全部投入生产。
我想知道从主干合并到生产中是否不是最好的选择 - 而不是来自系统测试。 理论上它应该是相同的代码 - 您将能够跟踪系统测试中的主干修订以及生产中的主干修订。
因此，为了清楚这一点，您将修订版从主干提升到系统测试，测试它，然后如果可以，将修订版从主干提升到生产（您可能必须再次启动一个干净的生产分支）。
您应该能够编写一些工具，使用 mergeinfo 来为您确认哪些修订版在系统测试中，但哪些修订版不在生产中。 使用 bugtraq 属性，您还应该能够知道哪些 CR 已完全合并到任一分支中，以及哪些仍有待修改。
如果您想要开始将不完整的主干提交提升到测试和生产中，那么您会遇到一些麻烦，尤其是从同一文件中选择更改时。 您可以右键单击单个文件并直接在文件级别合并（也许可以手动撤消某些更改），但是选择文件和更改将是非常手动的工作，并且您不会从工具中获得任何帮助。 此外，您跟踪的脚本开始变得极其复杂。
但请注意，这样做确实存在系统测试和生产之间代码漂移的风险。 我建议定期在分支之间进行比较，并确保您可以解释所有差异。 如果两个分支具有从主干合并的相同修订版，则它们应该是相同的，任何差异都应该是由于测试中尚未投入生产的修订版造成的，当然，生产中不应该存在未投入生产的修订版在测试中。
Wow, this actually sounds like a nice sane promotion system you've got here :)
In terms of tracking things, the simplest answer I have is to enforce a certain developer discipline - that is, only include 1 CR per commit.
Tortoise has support for the bugtraq properties which can help you here by ensuring that every commit comment includes at least one CR number - it may be a useful hint to tell developers that if they're including >1 tracking number for the commit then they're probably doing it wrong (unless one fix really does do multiple things).
So this will let you merge from trunk to systemtest just with the CR's you want. You can even use the tortoise merge ui to see what revisions in trunk haven't been merged into systemtest yet. But of course now you're going to want to go from systemstest to production with similar granularity - which is what the question is about.
The problem as I see it is that a single revision in systemtest can consist of multiple trunk commits, and you may not want them all in to production just yet.
I wonder if it might not be best to do the merge into production from trunk - instead of coming from systemtest. In theory it should be the same code - you'll be able to track what trunk revisions are in system test and what's in production.
So to be clear with that, you promote a revision from trunk to systemtest, test it, then if it's ok, promote the revision from trunk to production (you may have to start a clean production branch again).
You should be able to write some tools that use mergeinfo to confirm for you which revisions are in systemtest but which aren't in production. And using the bugtraq properties, you should also be able to tell which CR's are completely merged into either branch, and which have revisions still to go.
If you're going to want to start promoting less than a complete trunk commit into test and production, you're in a bit of trouble, especially if picking changes from the same file. You could right click on indiviudal files and merge in directly on the file level (and perhaps manually undo certain changes) but choosing the files and changes will be very manual work and you won't get any help from the tools. Also, you're tracking scripts start to get extremely comples.
Be warned however, that by doing this there's a very real risk of code drift between system test and production. I'd recommend regularly doing a diff between the branches and ensuring that you can account for all the differences. If the two branches have the same revisions merged from trunk, they should be identical, any differences should be because of revisions in test that aren't yet in production, and of course, there should never be a revision in production that isn't in test.
这是我们使用的一个很酷的库/工具：Savana。 对于每张票证，开发人员将使用 Savana 创建一个分支，并在准备好后将此用户分支提升回主干。 类似的方法可以解决您提出的问题：为任何给定任务创建一个分支，并在适当的时候将其合并回主干路径。
Here's a cool library/tool that we use: Savana. For each ticket, a developer will create a branch using Savana, and when ready promote this user branch back to trunk. A similar approach could solve the problem you presented: you create a branch for any given task, and merge it back into your main trunk path when the time is right.