我们目前正在为我们的项目使用 StarTeam,并且许可证即将到期。我们正在考虑迁移到 Team Foundation Server 或类似的东西,但有一个推动力(主要来自我和其他人)迁移到某种形式的分布式版本控制。问题之一是我们的变更经理希望能够通过变更请求跟踪和发布(如在 StarTeam 中),我不相信这可以通过开箱即用的 Mercurial 或 Git 轻松完成(请如我错了请纠正我)。
这是一个 15 年以上的产品,拥有数千个 java 文件和 PL/SQL 包,由 5-6 个开发子团队维护,总共有 30-40 名开发人员。对我来说,这似乎会使分布式存储库成为“尽早提交,经常提交”心态的噩梦。事实上,每个团队都在同一个存储库中开发完全不同的子系统,这在我看来更加糟糕。
我们当前针对任何变更的 StarTeam 流程如下:
- 锁定您要处理的文件,
- 进行全部更改并从网络驱动器上的副本中对其进行审核,
- 签入(并解锁)更改的文件,希望没有人强行破坏您的锁,
- 希望您的更改没有破坏从其他人更改到其他文件的构建
就个人而言,我认为“锁定”文件的想法是荒谬的。团队之间应该有足够的沟通,这样你就不需要了。
这里有没有人有类似规模项目的分布式存储库的经验?您能否就版本控制和/或变更管理解决方案提出任何建议?主要要求是系统能够管理客户发起的变更请求,并强制开发人员将他们的签入链接到一个。
谢谢。