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

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

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

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

合并后可能很容易忘记将svn切换回主干

开发人员可能在执行svn切换时，对其工作副本（在中断进行bug修复之前，他们正在为未来版本进行的工作）进行未提交的更改，并且意外地将这些更改合并到发布分支中

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

---

简而言之，我的问题是：当将bug修复从主干合并到发布分支时，如果开发人员还没有发布分支的工作副本，那么开发人员是否认为使用svn切换来进行合并是更好的做法，或者在本地其他位置查看发布分支的工作副本？提前谢谢

如今，磁盘空间通常很便宜，因此没有理由将所有内容都限制在一个工作副本中—单独查看分支可以提供大多数世界的最佳体验（独立于主干开发，忘记自己所在位置的机会更少，如果需要，可以轻松地从分支工作切换到主干工作，无需在完成后重新下载主干）.

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

除了偶尔的情况（如文档中所述），我会避免使用svn开关当您开始针对一个分支（比如主干）编写解决方案，然后得出结论认为在其自己的分支（svn copy trunk newbranch；svn switch newbranch）中更好时

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

---

如果发布分支很大，并且保存一个本地工作副本很麻烦（如果有很多发布分支在运行中，情况尤其如此）然后考虑使用分支/补丁管理器指定一个高级程序员来管理发布分支，他/她可以选择特定的干线变化合并到发布分支（ES）。。大多数人会将点击保存到他们的磁盘使用中，并且您可以更好地控制稳定的发布分支。

我经常使用SVN的稀疏签出功能。如果我签出存储库，我会以非递归方式签出

主干
/
标记
/
发布
文件夹（直接子文件夹，包括文件夹）。然后我进入每个存储库并进行更新，以便其直接子项也被签出。这样，我就可以在不浪费太多磁盘空间的情况下全面了解整个存储库

然后，我去完全递归地更新我想处理的任何东西。如果我完成了存储库中不能删除的东西，但磁盘上不再需要的东西，我只会再次将其更新到直接子代

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

我还没有遇到过这样一个存储库，其中的标记或分支数量如此之多，以至于只以非递归方式签出文件夹会浪费空间。
有趣的方法。我很好奇，按照我的理解，为什么你会经常签出标记，因为这些标记永远不应该被修改。@Todd：我想这只会让我不知道我不必考虑是否需要签出标记。我想我是在一个存储库中开始这整件事的，在那里我想捕捉某些新标记和分支出现的时间。因此，我稀疏地签出
标记
和
分支
文件夹。一旦我这样做了，我就意识到只进行反射会更好整个存储库结构都在我的磁盘上，所以我开始以同样的方式检查主干。磁盘价格不变，几百个空文件夹不应该让我考虑是否需要它们。
：）
+1我做的事情与另一个答案中描述的一样：