从StarTeam迁移到分布式源代码控制

Question

我们目前正在为我们的项目使用StarTeam,许可证即将到期.我们正在考虑迁移到Team Foundation Server或类似的东西,但是有一种推动(主要是来自我自己和另一个人)转向某种形式的分布式版本控制.其中一个问题是我们的变更经理希望能够通过变更请求进行跟踪和发布(如在StarTeam中),我不相信这可以通过Mercurial或Git开箱即用(请如我错了请纠正我).

这是一个拥有15年历史的产品,拥有数千个java文件和PL/SQL包,由5-6个开发子团队维护,共有30-40个开发人员.对我而言,这似乎会使分布式存储库成为"早期提交,经常提交"思维模式的噩梦.事实上,每个团队都在同一个存储库中处理一个完全不同的子系统,这使得它在我的脑海中变得更加糟糕.

我们目前的StarTeam流程适用于任何变更:

1. 锁定您要处理的文件,
2. 进行全面更改并通过网络驱动器上的副本进行审核,
3. 签入(并解锁)已更改的文件,希望有人没有强行破坏你的锁,
4. 希望您的更改不会破坏其他人对其他文件的更改

就个人而言,我认为"锁定"文件的想法是荒谬的.团队之间应该有足够的沟通,这是你不需要的.

这里有没有人在类似大小的项目上有分布式存储库的经验？您能对版本控制和/或变更管理解决方案提出任何建议吗？主要要求是系统能够管理客户发起的变更请求,并迫使开发人员将其签到链接到一个.

谢谢.

Answer 1

Git 和 Mercurial 都用于复杂程度远远超过您提到的项目。因此，根据您的项目团队规模使用 Git / Mercurial 应该不是问题。

本质上，我们希望对版本控制服务器进行更多控制。因此 Subversion 非常受欢迎。

然而，使用 Mercurial 或 Git 等 DVCS 来维护基于变更集的版本是很容易的。

您可以设置一个存储库，其中仅在审核后才推送变更集。这应该可以减轻变更经理的要求。

DVCS 确实具有优势，您可以轻松创建实验性分支或克隆，如果不起作用则将其丢弃，并在您认为它们已准备好时进行更改。经常提交/尽早提交是一种与 DVCS 配合良好的做法，因为您可以将更改推送到您自己的存储库。一旦烘焙完成，您就可以将其向上推以在团队内可用。

文件锁定已经是一个旧时代了。即使像 Subversion 这样的工具也没有使用它。这确实是工作的障碍。