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

Question

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

我的第一个想法是，也许开发人员根本不需要发布分支的工作副本，也许对主干的更改可以直接合并到存储库中的分支中。但我很快了解到 Subversion 不是这样工作的——你需要一个工作副本来合并。

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

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

如果我为这个过程编写了一些脚本，我可以防止 #1 成为问题，但 #2 让我更加担心。我想知道这是否会破坏这种方法。

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

Answer 1

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

Answer 2

我会避免使用 svn 开关，除非在偶尔的情况下（如文档中所述），当您开始针对一个分支（比如树干）编写解决方案，然后得出结论认为它在自己的分支中会更好（svn 复制树干新分支；svn 切换新分支）。

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

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

Answer 3

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

Answer 4

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

然后我会去完全递归地更新我想要做的任何事情。如果我完成了一些不会在存储库中删除但我不再需要在我的磁盘上的东西，我只需再次将其更新为直接子级。

这具有在磁盘上镜像存储库的实际布局的明显优势。这样很容易导航到某个分支。这种方法的另一个优点是简单的更新会告诉你新的标签和分支。

我还没有遇到一个存储库，其中标签或分支的数量如此庞大，以至于仅以非递归方式检查文件夹会浪费空间。