将错误修复合并到发布分支 - svn 切换到分支或获取单独的工作副本？
我对 Subversion 还比较陌生，希望能从更有经验的人那里得到一些见解。 我们正在采取一种方法，在主干上完成大部分开发工作（新功能和错误修复），并根据需要将错误修复合并到发布分支中。 通过这种方法，开发人员根本不会直接针对发布分支进行编码，而只会合并到其中。
我的第一个想法是，也许开发人员根本不需要发布分支的工作副本，也许对主干的更改可以直接合并到存储库中的分支中。 但我很快了解到这不是 Subversion 的工作方式 - 您需要一个工作副本才能合并到其中。
所以我的下一个想法是，开发人员仍然可以在本地保留一份代码库副本，将其指向主干，并在需要进行合并时进行 svn 切换到发布分支。 我可以预见到几个潜在的问题：
- 合并后可能很容易忘记切换回主干。
- 开发人员可能对他们的工作副本进行了未提交的更改（他们在修复 bug 之前正在为未来的版本进行更改），当他们进行 svn 切换时，这些更改仍然存在，并意外地将这些更改合并到发布分支。
如果我为这个过程编写一些脚本，我可以防止 #1 成为问题，但 #2 更让我担心。 我想知道这是否会破坏这种方法。
简而言之，我的问题是：当将错误修复从主干合并到发布分支时，开发人员还没有发布分支的工作副本，开发人员进行 svn 切换是否被认为是更好的做法进行合并，或者在本地不同位置查看发布分支的工作副本？ 提前致谢！
I'm relatively new to Subversion, hoping to get some insights from more experienced folks. We're taking an approach of doing the bulk of the development work (new features and bug fixes) on the trunk and merging bug fixes into release branches as needed. With this approach, developers won't be coding directly against release branches at all, only merging into them.
My first thought was that maybe developers don't need a working copy of the release branches at all, and maybe changes to the trunk could be merged into branches directly in the repository. But I quickly learned that that's not how Subversion works - you need a working copy to merge into.
So my next thought was that developers could still keep just one copy of the codebase locally, point it to the trunk, and do an svn switch to a release branch when they need to do a merge. A couple potential problems I could forsee:
- Might be too easy to forget to svn switch back to the trunk after the merge.
- A developer could have uncommitted changes to their working copy (something they were working on for a future release before they got interrupted to work on the bug fix) that would still be there when they do the svn switch, and accidentally merge those changes into the release branch.
If I put together some scripts for this process I could prevent #1 from being an issue, but #2 concerns me a little more. I'm wondering if that's a deal-breaker for this approach.
In a nutshell, my question is this: when merging bug fixes from the trunk to a release branch, where the developer does not already have a working copy of the release branch, is it considered a better practice for the developer to do an svn switch to do the merge, or to check out a working copy of the release branch in a different location locally? Thanks in advance!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我经常使用 SVN 的稀疏结帐功能。 如果我签出存储库，我会以非递归方式签出
trunk/tags/releases文件夹（直接子级，包括文件夹）。 然后我会深入了解每个人并进行更新，以便他们的直系孩子也能得到检查。 这样我就可以全面了解整个存储库，而不会浪费太多磁盘空间。然后我去完全递归地更新我想要处理的任何内容。 如果我完成了一些不会在存储库中删除的内容，但我的磁盘上不再需要这些内容，我只需再次将其更新为直接子级。
这样做的明显优点是镜像磁盘上存储库的实际布局。 通过这种方式很容易导航到某个分支。 这种方法的另一个优点是，简单的更新就会告诉您新的标签和分支。
我还没有遇到过一个存储库，其中标签或分支的数量如此巨大，以至于仅以非递归方式检查文件夹就会浪费空间。
I use SVN's sparse checkout feature a lot. If I check out a repository I check out the
trunk/tags/releasesfolders non-recursively (immediate children, including folders). I then go into each of them and update so that their immediate children are checked out, too. That way I have a full overview of the whole repository without wasting too much disk space.Then I go and update fully recursively whatever I want to work on. If I'm done with something that isn't to be deleted in the repository, but which I won't need on my disk anymore, I just update it to immediate children again.
This has the obvious advantage of mirroring the actual layout of the repository on your disk. It's easy to navigate to some branch that way. Another advantage of this approach is that a simple update will tell you about new tags and branches.
I have yet to come across a repository where the number of tags or branches is so enormously overwhelming, that just checking out the folders non-recursively waste space.
这是一个相当哲学的问题。 为了避免问题#2，我可能会单独进行合并结账。 这样可能需要更长的时间，但绝对更灵活。
That's a rather philosophical question. To avoid problem #2 I would probably go with a separate checkout for merging. It may take little longer that way but it is definitely more flexible.
如今磁盘空间通常很便宜，因此没有真正的理由将所有内容限制在一个工作副本中 - 单独检查分支可以提供大多数世界中最好的东西（独立于主干开发，更少的机会忘记一个在哪里，可以很容易地如有必要，可以从在分支上工作到在主干上工作来回交换，完成后不必重新下载主干）。
Disk space is generally cheap nowadays, so there's not really a reason to confine things all to a single working copy - checking out the branch separately gives the best of most worlds (independent of trunk development, less chance to forget where one is, can easily swap back and forth from working on branch to working on trunk if necessary, don't have to re-download trunk when done).
我会避免使用 svn switch，除非在偶尔的情况下（如文档中所述），当您开始针对一个分支（例如 trunk）编写解决方案，然后得出结论，在它自己的分支中会更好（svn copy trunk newbranch; svn切换新分支）。
您应该始终执行合并到本地工作副本中，这样您就可以在提交更改之前对更改执行比较（您应该养成在提交、任何提交之前始终执行此操作的习惯）并检查代码是否可以编译。
如果发布分支很大并且保留它的本地工作副本很麻烦（如果您有许多发布分支，尤其是这种情况），那么请考虑使用分支/补丁管理器 - 指定您的高级管理人员之一程序员管理发布分支，他/她可以选择特定的主干更改来合并到发布分支。 大多数人都可以避免对磁盘使用的影响，并且您可以更好地控制稳定的发布分支。
I would avoid using svn switch except in the occasional circumstance (as described in the docs) when you start coding a solution against one branch (say trunk) and then conclude that it would be better in its own branch (svn copy trunk newbranch; svn switch newbranch).
You should always perform merges into a local working copy, both so you can perform a diff on your changes before you commit them (which you should be in the habit of always doing before a commit, any commit) and also check that the code compiles.
If the release branch is large and it is cumbersome to keep a local working copy of it (which can especially be the case if you have many release branches on the go), then consider using a branch/patch manager - designate one of your senior programmers to manage the release branches and he/she can select particular trunk changes to merge to the release branch(es). Most people are saved the hit to their disk usage, and you keep the stable release branches under more control.