CVS 中的功能分支？
在这个特定的项目中，我有义务使用 CVS，所以即使我真的想切换到其他东西，比如 Git，我也不能。
所以，我真正的问题是这样的：我们有一个约定，每次发布版本时我们都会在 CVS 中创建一个新分支（我们也标记，但这不是重点）。 我们将这些称为版本分支，它们使我们能够轻松查看特定版本并对其进行热修复更改 - 这就是我们的次要版本。
但现在我要进行一些大型的、充满风险的更改，如果我在 Git 中工作，我会在眨眼之间创建一个功能分支。 然而，在 CVS 中工作时，我尝试在另一个项目中创建功能分支，发现事情很快就变得混乱了。 我最终得到了很多分支，但我不知道哪些分支已同步，哪些分支需要合并，哪些分支不再使用。
那么，越来越接近问号的是，在 CVS 中使用特征分支是否可行？ 它们是否太麻烦而不值得，还是我最终会因为没有使用它们而感到遗憾？ 我是否应该硬着头皮开始在 HEAD 中编码，但改变编码过程以尽可能以最不引人注目的方式引入更改？
I'm duty-bound by policy to use CVS in this certain project, so even though I'd really to switch to something else, like Git, I cannot.
So, my real question goes like this: We have a convention that we create a new branch in CVS every time we make a release (we also tag, but that is besides the point). We call these version-branches, and they allow us to easily check out a specific version and make hot-fix changes to it - this is what our minor-releases are.
But now I have some large-ish, risk-ridden changes coming up and if I was working in Git, I'd be creating a feature-branch in the blink of an eye. However, working in CVS, I tried creating feature branches in another project and found that things quickly turned out messy. I ended up with lots of branches and I lost track of which branches were synched, which needed merging and which were no longer in use.
So, inching closer to the question mark, is it feasible to use feature-branches in CVS? Are they too much trouble to be worth it or will I eventually end up being sorry for not using them? Should I bite the bullet and just start coding in HEAD but bend my coding process to introduce the changes in the most unobtrusive way possible?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
如果您是唯一在功能分支上进行开发的人，您可以简单地使用 Git 作为您的“沙箱开发”系统，然后一旦完成更改，将它们合并到您的 CVS 存储库中。
您仍然可以从中间工作产品的源代码控制中受益。
If you are the only one developing on the feature-branch, you could simply use Git as your "sandbox development" system and then once you have the changes done, merge them into your CVS repository.
You still gain the benefit of source control for your intermediate work product.
有一个关于分支策略的精彩讨论，称为 流线 可能会有所帮助 - 它描述了使用特征分支的优点和缺点。
它还涵盖了您可能想要实施的代码行所有权和策略的选项
There is an excellent discussion of branching strategies called streamed lines which might help - it describes the advantages and disadvantages of using feature branches.
It also covers options for code line owenership and policies that you might like to implement
需要考虑的一件事是，在完成功能分支并将其与主干合并后，实际上关闭功能分支。 在这种情况下，关闭只是意味着放弃分支，而不是真正的删除。
一旦工作被合并，分支就真的没有必要“存在”了。
为了快速识别哪些分支是功能分支，我建议使用命名约定泄漏“FEAT_MY_FEATURE”或“FEAT_20080926”（开始日期？）。 这使得在浏览存储库结构时很容易忽略所有这些功能分支。
One thing to consider is to actually close the feature-branch when you are done with it, once you have merged it back with the main trunk. In this context, close simply means abandon the branch, not a real deletion.
Once the work is merged, there really is no need for the branch to "exist".
In order to quickly identify what branches are feature branch, I would suggest having a naming convention leak "FEAT_MY_FEATURE" or "FEAT_20080926" (start date?). This would make it easy to disregard all those feature branches when browsing the repository structure.
我在这样的环境中工作了几年，这种做法很常见，而且真的很痛苦。 确保合并是项目计划的一部分，因为它们会消耗大量时间并且是延迟的根源。
记录分支机构并分配他们具体的职责有一点帮助。
我们必须创建一个工具来帮助我们增量地合并更改（一次一个更改，而不是合并分支的尖端），因为如果两个分支出现分歧，CVS 的表现就会不佳。
经常同步（至少每周一次）。
我认为回想起来，解决这个问题的最佳方法是确保分歧保持最小，并通过使用 Scrum 等方式将风险开发分散到不同的里程碑中。
我还鼓励您阅读SCM 模式。 这本书包含了很多好的建议。
I have worked in an environment for several years where this was common practice and it was really painful. Make sure that the merges are part of your project plan because they are going to consume a lot of time and are sources of delay.
Documenting the branches and assigning them specific responsibilities helped a little.
We had to create a tool to help us merge changes incrementally (one change at a time, instead of merging the tip of branches) because CVS does not behave well if the two branches diverge.
Often synchronize (at least once a week).
I think the best way to approach this in retrospect would be to make sure that divergence remains minimal and splitting the risky development in different milestones by using Scrum for example.
I also encourage you to read SCM Patterns. This books contains a lot of good advices.