如果我们从 TFS 迁移到 Fogbugz Kiln,我们可能会面临哪些问题?
目前我们正在使用 TFS 进行源代码控制,我们正在考虑迁移到 Kiln 的选项。
我们是完全基于 Microsoft 开发工具的公司,因为我们使用 Visual Studio .net、SQL 服务器、TFS、Windows 服务器等。
搬家的原因似乎是:
- 窑中更好的代码审查工具
- 更好的分支合并管理。
有人已经这样做了吗?当我们将 Visual Studio 与 Kiln 一起使用时,有人知道问题吗?
我无法完全回答您的问题,因为我不使用(也从未使用过)TFS。但是,我的雇主使用 StarTeam,这在源代码控制方面非常典型。
对我来说,从传统的 SCC 签出/签入方法转向分布式模型是第一个心理障碍。为了克服这个障碍,我发现http://hginit.com/上的教程很有帮助。
至于将 Kiln 用于 VS,我同时使用 Kiln 客户端(本质上是 TortoiseHg)和VS 2010 的插件。我可以从 Windows 资源管理器和 Visual Studio 提交、拉取、推送等。除了学习 mercurial 和分布式版本控制的工作原理之外,我没有遇到任何问题。
至于其他问题,我能想到的唯一问题是更新任何构建服务器或持续集成服务器以从适当的存储库中提取。
Mercurial 中的分支更好,但这是有代价的:您将拥有更多的分支,并且开发人员更容易犯错误并在错误的分支中做某事。灵活性可能会导致混乱。
但最重要的是你的过渡计划。如果您在 TFS 中有很长的提交记录,您可能希望保留它。不幸的是,当我需要一个时,似乎没有直接的转换工具来帮助将 TFS 转换为 Hg。我尝试使用 带有 tfs2svnhg convert
的 tfs2svn ,但 tfs2svn 遇到了复杂的重命名问题,我被迫编写了一个愚蠢的直接转换实用程序。
去年秋天,我们从 Sourcegear 的 Vault (w/Bugzilla) 切换到 Kiln (w/ FogBugz)。我们所有的开发人员都喜欢将代码审查提交到案例(错误/票证)到规范/要求的紧密集成。
掌握中央存储库的组织需要一些尝试和错误。Kiln(和代理的 Mercurial)非常灵活,您可以轻松构建一个过于简单或过于复杂的组织结构。您可以轻松地进行分支和合并,从而大大减轻了这种情况。我们的目标是构建一个系统,该系统只允许将审查过的代码放入暂存存储库,然后可以部署该存储库以发布给 QA。最终确定我们的存储库组织以简化此过程大约需要 6 周(主要是反复试验)。
在 Vault 中(从哲学的角度与 Subversion 相媲美),您可以轻松地提交一个可能需要花费数小时时间来逆转的更改,而在 Kiln 中,进行更改并将其丢弃是微不足道的。虽然我不能代表 TFS,但在 Vault 中编译发布是一场噩梦。花费 90 分钟的生产力并将其丢弃。在 Kiln 中,编写一些 Perl 脚本来自动化构建/发布是微不足道的,如果不进行几分钟的手动审查,现在几乎可以立即完成。
最大的挑战(正如 Helgi 所建议的)是管理分支机构。一些开发人员发现这非常容易,而另一些开发人员则很难做到。
也没有从 Vault 到 Kiln 的转换路径,因此我们维护 Vault 服务器实例以用于存档目的,并从 Kiln 重新开始。
6 个月后,它改变了我们的生活(变得更好)。
Codereview 存在于 TFS 中(只需下载一个免费的扩展),merge 在 TFS 中非常好,报告在 TFS、方法、集成甚至价格方面更好。以我谦虚的观点。但两者都是很棒的产品,如果你工作或需要分布式 sc 或混合团队(linux 等),TFS 也有解决方案,但不是那么便宜