从StarTeam迁移到分布式源代码管理

Question

我们目前正在为我们的项目使用StarTeam，许可即将到期。我们正在考虑转向Team Foundation Server或类似的方式，但是推动（主要来自我和另一个人）转向某种形式的分布式版本控制。其中一个问题是，我们的变更经理希望能够通过更改请求进行跟踪和发布（如StarTeam中所述），我不相信这可以通过Mercurial或Git开箱即用轻松完成（请如我错了请纠正我）。

这是一个拥有数千个Java文件和PL/SQL包的15岁以上的产品，由5-6个开发小组维护，总共有30-40个开发人员。对我而言，这似乎会使分布式存储库成为“早期提交，经常提交”思维模式的噩梦。每个团队都将在同一个存储库中完全不同的子系统上工作这一事实使得它在我的脑海中变得更加棘手。

我们对任何改变目前的StarTeam过程是这样的：

1. 锁定的文件（S）你想工作，
2. 会让你的整个变化，并把它从一个副本回顾了网络上开车，
3. 入住（和解锁）已更改的文件，希望有人没有强行破锁的，
4. 希望你的变化是从别人的变化构建不破其他文件

就我个人而言，我认为“锁定”文件的想法是荒谬的。团队之间应该有足够的沟通，这样你就不需要了。

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

谢谢。

Answer 1

Git和Mercurial都用于复杂程度远远超过您所提及的项目。因此，使用Git/Mercurial来解决项目团队规模问题不应该成为问题。

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

如何根据使用DVCS（如Mercurial或Git）的变更集来维护版本很容易。

你可以有一个回购设置，只有在回顾后才能推送变更集。这应该可以减轻变更经理的要求。

DVCS确实带来了优势，您可以轻松创建实验分支或克隆，如果它不起作用，就会抛出它们，并在您认为它们已准备好用于黄金时段时进行更改。经常提交/提早提交是一种适用于DVCS的实践，因为您将更改推送到自己的回购站。一旦烘焙完成，您可以向上推动团队内的可用性。

锁定文件是一个旧时代。它甚至没有被Subversion等工具所使用。这实际上是妨碍工作的障碍。

Answer 2

Git不会提供您正在寻找的“变更管理”流程。这是商业版本控制系统喜欢做广告以吸引企业闪亮物品的管理要求之一。这并不意味着你不能这样做，它只是在git的目的之外。很像，身份验证和访问控制（您可以使用ssh和gitolite，但git本身不提供这些服务）。除非您使用常见的错误跟踪工具，否则您可能需要自行开发此集成。

锁定文件总是错误的。这就是“合并”的意义。

我目前正在与10个开发人员合作开发代码大约200,000行代码，并且git的工作非常好。我们的团队比其他项目上的git还要大一个数量级。 Git的优势在于合并，这就是它如何处理多个开发人员和大量提交。请记住，每一次推动都是git中的一个合并，无论它看起来与否。您的本地存储库可能有一个名为master的分支，但与中央存储库中的master不同。为了同步它们，你需要做一个合并，有时候这只是一个“快速合并”。

我们不打扰强制链接改变请求。当我考虑编写一个接口来做到这一点时，我碰到的一个问题是如何让愚蠢的跟踪系统意识到每个分支都存在一个错误。一个简单的钩子是不够的。

你应该转移到git的开发过程改进。对我而言，它从根本上改变（改进）了我编写代码的方式。如果没有所有来自昂贵的IBM工具的预先包装的子弹，您将面临一个挑战，即要提供一个git更好地进行业务变更管理的案例。真正的问题是，一旦你拥抱git，你将永远无法再与任何其他工具一起工作，无论他们出现多么好的商业案例......

Answer 3

我们已经非常成功地使用git 。我们遵循这个过程。很容易跟踪任何问题上取得进展：

https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR

如果你看看评论，有迹象表明看着过程中的一些有影响力的人。这是一种非常棒的工作方式，希望写作能够为您提供所需的弹药。对于TFS具体的东西，看看这里：

TFS branching, what are the advantages（误导性标题）

Answer 4

我在评论中写道，但我认为这是重要的，以至于它值得一个完整的答案。

我作为Mercurial顾问工作，当我与客户交谈时，他们经常要求“变更请求”和“变更管理”。当我告诉他们Mercurial有没有这样的概念，他们感到惊讶。像Git一样，Mercurial是一个重点工具。它确实使用版本控制，并允许您定义顶层的工作流程。如果您愿意，您可以根据更改请求来说明工作流程，但您不必这样做。

处理变更请求的典型方法是将它们放入某种问题追踪器中。可以使用Mercurial中的命名分支或使用Git中的提交消息中的注释完成将变更集与CR链接。当推送到中央服务器时，问题会被挂钩更新。

你提到应该处理那些不应该成为发布版本的变化。最简单的方法是在知道变化稳定之前不合并到主线。您仍然需要在分支上运行测试，因此您需要一个可以逐个测试每个分支的测试设置。为了测试分支之间的依赖关系，您暂时合并它们并对结果运行测试。您可以继续在分支上工作，随后的合并会很小。

最后，当您想承诺释放分支时，将其合并到主线中。

Answer 5

以下是将StarTeam项目转换为GIT存储库的小型Web应用程序。

http://dl.dropbox.com/u/101447754/startgit.tar.gz

我发展，因为在我的工作决定迁移，并给了可能性，如果没有以前的研究工作，任何一组做出这样的过程。

现在：

StartGIT ES UNA sencilla herramienta对trabajar CON Controladores德Versiones，苏鳍ES PODER convertir未repositorio连接StarTeam执行GIT，对ELLO SE脑水肿USO德尔脚本 “svnimporter-1.2-ST” obtenido恩“http://www.polarion.com/user/direct_register.php?dl=svnimporterst”：

特纳instalado： - GIT - 混帐svn的 - java的 - Apache2的

Pasos： - Descomprim IR “startgit.zip” - Colocar LA carpeta descomprimida “startgit” 恩报上级目录 “/无功/网络/” - Abrir navegador网络Ÿcolocar LA siguientedireccción的 “http：//本地主机/ startgit”

// -------------------------------------------------- -----------

StartGIT是一个简单的工具，其目的是将一个Starteam存储库转换为GIT。

此脚本使用 “svnimporter-1.2-ST” 获得 “http://www.polarion.com /用户/ dl的direct_register.php = svnimporterst？”

已安装： - GIT - GIT中-svn - java的 - Apache2的

步骤： - 在 “/无功/网络/” 将解压缩文件夹 “startgit” - - 打开网页浏览器，“HTTP解压 “startgit.zip” ：//localhost/startgit“

Answer 6

目前有一个StarTeam的git远程助手，它也可以用来将StarTeam的历史记录导入到git存储库中，该git存储库可以作为StarTeam的替代品。

的代码是在https://github.com/warrenfalk/git-st/tree/st_to_git_migration_features（它的git-ST的一个特性分支能够做这种进口的一个分支的分支st_to_git_migration_features。）

看到：https://github.com/warrenfalk/git-st/blob/st_to_git_migration_features/README.migration.md关于如何完成它的说明。

我已经使用它来成功将StarTeam的历史记录导入git存储库。