尚未进行单元测试的代码的版本控制
我的团队有十几名工程师，其中一些负责的模块需要 2-3 周才能完成。
现在我们只有在单元测试完成后才将各个模块集成到CVS的主分支中。
问题在于，在长达 2-3 周的时间里，代码只保存在工程师的计算机上，并且不受版本控制。
使用的编程语言是C。
有没有什么优雅的方法来管理版本控制下的非单元测试代码。
谢谢
詹姆斯
My team has a dozen engineers, some of whom work on modules that will take 2-3 weeks to complete.
Now we integrate each module to the main branch of CVS only after unit testing is completed.
The problem with this is for a good 2-3 weeks the code sits only on an engineer's computer and is not under version control.
The programming language used is C.
Is there any elegant way to manage non unit tested code under version control.
Thanks
James
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您在“主”分支办理入住前 2-3 周的流程并不反常，就像类似的重新设计“根管”工作一样（有时需要进行认真的重组工作）。
然而，我往往会对版本控制之外的那么多时间感到非常紧张。
“检查点”。
强烈建议本地开发人员在 2-3 周内使用 Mercurial 或 Git 进行本地版本控制，然后您可以将“最终确定”的项目签回（主）CVS 分支。它们确实是为完全该场景而构建的。
这就是我们所做的——它有效，并且它使得各个开发人员之间的差异和补丁以及协作变得非常简单。
（对于我们来说，Mercurial 是本地的，Subversion 是“主要”版本控制系统。）
Your process of 2-3 weeks before check-in to the "main" branch is not out-of-the-norm, as would be a similar re-design "root canal" effort (serious restructuring work that is sometimes necessary).
However, I would tend to get pretty nervous about that much time outside of version control.
"check-point".
A strong recommendation is that the local developer use Mercurial or Git for local version control for that 2-3 weeks, and then you can check the "finalized" project back into the (main) CVS branch. They are really built for exactly that scenario.
That's what we do -- it works, and it makes diffs-and-patches and collaboration between individual developers quite trivial.
(For us, Mercurial is local, Subversion is the "main" version control system.)
嗯，对我来说，在版本控制之外编程就像倒车行驶：技术上可行，但通常会适得其反。
从这个意义上说，我想说，任何其他以某种方式允许开发人员持续将他们的工作保持在 VC 下的方法都会比什么都没有更优雅。为此，有许多已知的方法 - 谷歌搜索版本控制分支策略会显示大量资源来解释您的选项和选择标准。
如果不进行实验，很难判断哪些选项更适合您的项目。在研究我上面提到的资源时，我建议检查通常称为“功能分支”的详细信息。该策略与您所描述的“需要 2-3 周才能完成的模块”的情况非常匹配 - 尽管我不敢打赌它最适合您的团队。
另请注意，至少对于“内部”开发人员来说，您可以选择使用版本控制系统，而不是老式且不方便的 CVS。
Hm well to me programming outside of version control is like driving with reverse gear: technically doable but generally quite er counterproductive.
In that sense, I would say any other approach that somehow allows your developers to continuously keep their work under VC would be more elegant than nothing at all. For that, there are many known ways - googling for version control branching strategy shows plenty resources explaining your options and criteria how to choose.
Without experimenting it's rather hard to tell which of these options is a better fit for your project. When studying resources I refer to above I'd recommend to check details of what is usually called Feature Branch. This strategy rather closely matches the case you describe "modules that will take 2-3 weeks to complete" - although I wouldn't bet on that it's the best fit for your team.
Note also that at least for "internal" developers needs you have an option to use version control system other than old-fashioned and inconvenient CVS.
如果您的公司政策要求所有代码在签入之前进行单元测试，我认为这是非常好的政策，您应该这样做：编写单元测试，甚至可能在编写代码之前。
但如果我误解了你的意思，只是在一切完成后应该进行大型测试，那么那就太糟糕了。您肯定会遇到讨厌的集成问题。如果您无法更改该策略，至少拥有本地 VCS。另外，您可以使用“featureX_Enabled”开关进行配置，并在签入时尽量不要忘记将其设置为“0”。
无论如何，切换到 Git 或 Mercurial，使用它们会轻松得多。
If your company policy requires all your code to be unit tested before checking in, I think it is pretty good policy, and you should do just that: write your unit tests, perhaps even before writing code.
But if I misunderstood you and it is just that there should be large testing session when everything is done, well, then it is too bad. You will definitely encounter pesky integration problems. If you cannot change that policy, at least have your local VCS. Also, you could have config with "featureX_Enabled" switches, and try not to forget to set it to '0' when checking in.
Anyway, switch to Git or Mercurial, they would be so much less painful to use.