根据实际需要为开发人员确定正确的工具

Question

我将从一些背景知识开始，我可以提出哪些合理的问题，以便为我的开发团队的真正需求确定正确的源代码控制工具？

开发人员使用ClearCase，因为IBM咨询主管项目团队安装了它，以便在大型内部项目中使用。在此项目期间，Rational Suite用于执行任务，测试等。一旦完成此项目，仅使用ClearCase作为存储源代码的方法。不幸的是，此时ClearCase被开发人员用作强制工具。在2009年初启动全球项目之前，国外的其他同事主要使用SVN。全球项目现在要求这些开发人员使用ClearCase Remote Client（CCRC）。

我观察到这个工具虽然非常强大，但对于它们的开发需求来说太过分了。 UCM过程是在现场实施的，但是对于过程步骤，特别是在使用CCRC时，有很多人表示沮丧。另一个问题是其他开发工具要求文件可写，以便完成开发任务，导致开发人员劫持才能工作。

由于许多公司现在正在外包和重新评估他们的所有战略，以保持竞争力和财务可行性，我想验证我们是否有正确的工具，并且不仅支持今天的开发活动和需求，但也为了未来。我期待着更好地了解这个问题。

Answer 1

  

我可以提出哪些合理的问题，以便为我的开发团队的真正需求确定正确的源代码控制工具？

IMO，其中一些问题包括：

• 现状是什么？
• 为什么现状如此？ [也许是政治：IBM咨询主导项目]
• 我们为什么要改变（激励措施是什么）？
• 我们可以改变的替代方案是什么？
• 通过改变替代方案，我们会获得什么，将会失去什么？
• 与更改相关的成本（或努力）是多少？

Answer 2

通过阅读“What are the basic ClearCase concepts every developer should know ?”，您可以更好地了解当前情况（ClearCase）的潜在优势

由于CCRC用于通过RCP接口和远程基于Web的视图服务器访问ClearCase，因此它看起来像是DVCS（分布式VCS）的廉价替代品。 这意味着可能的替代方案是使用免费的DVCS（Git，Mercurial，...）

我在过去的6年中使用UCM，并发现它对于具有多个并行开发的多个相互依赖的“组件”（即“一致的文件组”）的大型项目非常有用。

但是，对于小型独立项目，我不建议采用这种重型方法（UCM），具有简单的线性开发生命周期。

---

因此，要完成一组问题proposed by ChrisW

• 在VCS下管理的典型项目的大小是多少？
• 他们的类型是什么（相互依赖或相当自治？）
• 这些项目所遵循的workflow of merge是什么（一个简单的项目可能表明Subversion是一个可能的候选者，一个更复杂的项目需要更严肃的工具来进行大量合并）
• 什么是网络类型（中央存储库始终是最佳配置，还是具有分发/复制功能的本地存储库不会更适应？）

Answer 3

谢丽尔，没有尝试解决您的解决方案 - CCRC显然是您的远程开发人员的选择，但也存在ClearCase Multisite。如果存在流程问题，那么提供本地而非远程访问基础设施将是一个短期解决方案，而不是移动SCM。