我有责任在这个特定的项目中使用CVS，所以即使我真的想切换到别的东西，比如Git，我也不能。所以，我真正的问题是这样的：我们有一个约定，我们每次创建一个发布（我们也标记，但除此之外），我们在CVS中创建一个新的分支。我们将这些版本分支称为这些分支，他们允许我们轻松检出特定版本并对其进行修复 - 这是我们的次要版本。CVS中的功能分支？
但是现在我有一些很大的风险很大的变化，如果我在Git工作，我会在眨眼之间创建一个功能分支。但是，在CVS工作时，我试图在另一个项目中创建功能分支，发现事情很快就变得杂乱无章。我结束了很多分支机构，并失去了哪些分支机构同步，哪些分支机构需要合并，哪些分支机构不再使用。
因此，靠近问号逐渐靠近，在CVS中使用功能分支是否可行？他们是否太麻烦是值得的，或者我最终会因为不使用它们而感到抱歉？我应该咬紧牙关，刚开始在HEAD中编写代码，但是要弯曲我的编码过程，以尽可能以最不显眼的方式介绍变化？
如果你是唯一一个在功能分支上开发的人，你可以简单地使用Git作为你的“沙盒开发”系统，然后一旦你完成了改变，将它们合并到你的CVS仓库中。
您仍然从中级工作产品获得源代码管理的好处。
有一点要考虑的是实际接近功能分支，当你用它做，一旦你与主干线合并回来。在这种情况下，关闭意味着放弃分支，而不是真正的删除。
工作合并后，确实不需要分支“存在”。
为了快速识别哪些分支是功能分支，我建议命名约定泄漏“FEAT_MY_FEATURE”或“FEAT_20080926”（开始日期？）。这样可以在浏览存储库结构时轻松忽略所有这些功能分支。
你说的这个“关闭”是什么？我认为有一种方法可以删除分支，但关闭分支并不是我以前听说过的。谷歌搜索是暗示它可能是基于约定：http://www.x.org/wiki/CvsBranchnames – 2008-09-26 11:29:00
我的意思是关闭是“停止使用它们/忘记它们”一旦合并发生，放弃分支 – Benoit 2008-09-26 12:05:29
有一个关于分支策略的优秀讨论，称为streamed lines这可能会有所帮助 - 它描述了使用功能分支的优缺点。
它还包括代码行owenership以及您可能想实施的政策选项
有很多东西需要阅读。该文件是旧的。但是，我会仔细看看它。 – 2008-09-26 13:00:00
我曾经在一个环境中工作了几年在那里，这是常见的做法，这是非常痛苦的。确保合并是您的项目计划的一部分，因为它们将耗费大量时间并成为延迟来源。
记录分支机构并为其分配具体责任有一点帮助。
我们必须创建一个工具来帮助我们逐步合并更改（一次更改一次，而不是合并分支尖端），因为如果两个分支发散，CVS表现不佳。
经常同步（至少每周一次）。
我认为回顾这个过程的最好方法是确保分歧保持最小，并通过使用Scrum来分隔不同里程碑中的风险发展。我也鼓励您阅读SCM Patterns。这本书包含了很多好的建议。
我接受了这个回答，因为这是我决定去做的方式。 – 2008-10-06 10:49:32