Version control CM用户的源代码控制

我希望将我的团队带入本世纪，并使用源代码控制。开发人员非常有能力处理源代码控制软件-无论是基于命令行还是基于GUI，Windows还是-Nix

他们一直在本地和单独处理代码（这让我非常害怕）的原因是，我们的CM小组在技术上不够精明，对整个签入/签出过程也不太熟悉

是否有面向CM组的源代码控制软件？我正在考虑一个允许他们从所有已签入的文件中选择一个版本的文件，并将其标记为他们试图创建的构建

如果考虑CM（配置管理）组负责发布管理过程，那么您可以将它们与任何（d）VCS工具的“技术细节”隔离开来，您可以通过建立一个好的发布过程来选择。 发布包括使某处可见（一个共享目录，一个工件存储库，如，专用于发布的文件等）：

• 运行程序所需的交付（一组二进制文件及其依赖项）
• 这些二进制文件的清晰版本列表（SVN修订号或标记、git标记、Nexus组工件版本等），允许开发人员在CM组返回要修复的缺陷列表时找到确切的代码集
• 解释部署的文档

构型管理组负责这组交付，管理不同部署环境（集成、UAT、预生产、生产等）之间的发布过程和推广，而无需处理VCS工具

---

这也加强了开发人员和产品之间的紧密分离（在环境和流程方面），允许开发人员采用他们想要的任何开发工作流，而不影响CM组的工作方式。

这就是“CM组”？您现在使用哪种构建工作流？开发人员在其选择的位置开发并保存其文件。当我们需要构建时，CM会询问开发人员最新版本在哪里，将该目录（或单个文件，如果是这样）复制到具有构建名称的新目录中，然后基于这些文件进行构建。我认为在选择SCM之前，您必须先建立良好的开发工作流。当前的“无管理的无政府状态”非常可怕。之后，几乎所有的SCM（可能是DVC，因为它们支持更多类型的灵活工作流）都将满足您的需求相信我，我完全同意-我们仍在努力改进工作流，但我正试图展望SCM方面的未来。我刚刚研究了DVCS，发现了一个很棒的教程，我计划使用它来指导Mercurial：（一些开发人员过去使用过Subversion）哇。Nexus听起来和我要找的一模一样；假设您使用过Nexus，那么设置东西（移入文件、设置用户等）对您来说有多容易？@redhospike相当容易，一旦您理解了这个想法（Nexus书籍帮助：）。当您存储过多的二进制文件时，很容易做到：Nexus referential是一个具有命名约定的目录集合，因此删除内容非常简单（而不是删除VCS数据库中的版本）。