将错误修复合并到发布分支 - svn切换到分支或获取单独的工作副本？

Question

我对Subversion相对较新，希望从更有经验的人那里获得一些见解。我们采取的方法是在主干上进行大量的开发工作（新功能和错误修复），并根据需要将错误修复合并到发布分支中。使用这种方法，开发人员根本不会直接针对发布分支进行编码，只会合并到它们中。

我的第一个想法是，开发人员可能根本不需要发布分支的工作副本，并且可能会直接在存储库中将对trunk的更改合并到分支中。但我很快就知道Subversion的工作原理并不是这样 - 你需要一个工作副本才能合并。

所以我的下一个想法是，开发人员仍然可以在本地只保留一个代码库副本，将其指向主干，并在需要进行合并时执行svn切换到发布分支。我可以预见几个潜在的问题：

1. 合并后可能太容易忘记svn切换回主干。
2. 开发人员可能会对他们的工作副本进行未提交的更改（他们正在为未来的版本工作，然后他们会在中断错误修复工作），当他们执行svn切换时仍然存在这些更改，并意外地合并这些更改更改为发布分支。

如果我为这个过程整理了一些脚本，我可以防止＃1出现问题，但＃2会让我更加担心。我想知道这是否是这种方法的突破。

简而言之，我的问题是：当将来自主干的错误修复程序合并到发布分支时，开发人员还没有发布分支的工作副本，对于开发人员来说，它是否被认为是更好的做法一个svn开关来进行合并，还是在本地的不同位置检出发布分支的工作副本？提前谢谢！

Answer 1

现在磁盘空间通常很便宜，所以没有理由将所有内容限制在一个工作副本中 - 单独检查分支可以提供最好的大多数世界（独立于主干开发，更少忘记一个是，如果需要，可以轻松地在分支机构上进行来回切换，在必要时可以在主干上工作，不必在完成后重新下载主干。）

Answer 2

我会避免使用svn开关，除非在偶然情况下（如文档中所述）当你开始针对一个分支（比如trunk）编写解决方案然后得出结论它在自己的分支中更好（svn copy trunk） newbranch; svn switch newbranch）。

您应该始终将合并执行到本地工作副本中，这样您就可以在提交之前对更改执行差异（您应该习惯于始终在提交之前执行此操作，任何提交）并检查代码是否编译。

如果发布分支很大并且保留它的本地工作副本很麻烦（如果你有很多发布分支，尤其如此），那么考虑使用分支/补丁管理器 - 指定一个您的高级程序员管理发布分支，他/她可以选择特定的主干更改以合并到发布分支。大多数人都保存了他们的磁盘使用量，并且您可以更好地控制稳定版本分支。

Answer 3

这是一个相当哲学的问题。为了避免问题＃2，我可能会使用单独的结帐进行合并。这可能需要更长的时间，但它肯定更灵活。

Answer 4

我经常使用SVN的稀疏结账功能。如果我签出存储库，我会非递归地检查trunk / tags / releases个文件夹（直接子项，包括文件夹）。然后我进入每一个并更新，以便他们的直接孩子也被检查出来。这样我就可以全面了解整个存储库，而不会浪费太多磁盘空间。

然后我继续完全递归地更新我想要的工作。如果我已经完成了一些不能在存储库中删除但我不再需要在磁盘上删除的东西，我只是再次将它更新为直接的孩子。

这具有镜像磁盘上存储库的实际布局的明显优势。通过这种方式导航到某个分支很容易。这种方法的另一个优点是简单的更新将告诉您有关新标签和分支的信息。

我还没有遇到一个存储库，其中标签或分支的数量非常庞大，只是非递归地检出文件夹浪费空间。