TFS for Java - 糟糕的主意？

Question

我们正在考虑将TFS用于基于.NET的项目和任务管理平台.有些团队只使用Java开发,他们对SVN(Subclipse)非常满意.

我们的经理提出了以下问题:

• 我们是否应该将Java团队迁移到TFS？
• TFS(仅限源代码控制)是否处理​​好Java项目？
• 将我们的Java代码库和历史从Subclipse迁移到TFS是一件痛苦的事吗？

目前,出于可维护性原因,我们希望将TFS用作唯一的源控制平台.我们希望避免让我们的IT人员支持多个系统.

谢谢

Answer 1

完全披露,我在为TFS编写Java工具的团队工作,所以把这个答案视为适当的偏见:-)

就TFS而言 - 所有代码都是相同的.它只是文件中的字节,它检入版本控制.像所有SCM系统一样,它不关心文件的编写语言.

Microsoft 为Eclipse提供了一个完整,丰富的TFS插件(称为Team Explorer Everywhere).这为基于Eclipse的IDE提供了完整的源代码控制,工作项跟踪,构建,共享点,报告访问等.它是用100%Java编写的,直接与TFS公开的Web服务进行对话.

此外,我们还为TFS提供了一个跨平台的命令行客户端,以便您可以从所选操作系统(Mac,Linux,Solaris,HP-UX,Aix等全部支持的命令行)的命令行与TFS对话.

最后,如果您有使用Java编写的工具想要与TFS交谈,那么他们可以使用TFS SDK for Java,这是我们用来创建Eclipse集成和跨平台命令行客户端的完整API,但是打包了样本和片段,随时可以使用您的应用程序重新分发.

在构建时,您有几个选择.如果您想坚持使用当前的构建服务器,那么很可能这已经支持与TFS(所有流行的开源构建服务器都可以)进行通信.除此之外,Microsoft还提供TFS Build Extensions,允许您在Team Foundation Build服务器上运行基于Ant或Maven的构建.如果您在构建过程中执行JUnit测试,则构建结果(以及任何警告或错误)将与任何JUnit测试数据一起发布回TFS.您还可以在Eclipse IDE中创建和管理构建定义,并有一个位置来管理对它们的访问等.

所以 - 对Java的支持程度非常高,微软已经在这方面进行了持续的投资.我们最近发布了一些用于Eclipse的TFS 2010 Power Tools,我们还一直在发布Team Explorer Everywhere 11的预览版本以及Team Foundation Server 11(我们是公司内部的同一个团队).

要从SVN导入历史记录,这与将历史记录从任何SCM工具导入TFS(或将TFS导入任何SCM工具)相同.你有几个选择.您可以拍摄快照并切换特定点(例如发布),也可以迁移历​​史记录.要从SVN迁移历史记录,可以使用一些合作伙伴解决方案,包括Timely Migration中的一个,我见过很多客户都取得了成功.

希望有所帮助.

Answer 2

在使用TFS开发Java/JVM项目一年后,我想劝阻任何人这样做.虽然TFS可能被认为是.NET开发人员的顶级产品,但您将找不到任何具有任何经验的Java开发人员.有Eclipse的插件和IntelliJ的端口,但我两个都运气不好,虽然我猜它主要是因为TFS不像我用过的任何其他VCS那样工作.

在我们的团队中,我们估计由于TFS和由此引起的并发症导致10-15%的开销.由于TFS决定覆盖文件,因TFS更新不完整而导致数天的故障排除,因此工作天数丢失.我们在6个月内完成了一个分支,因为整个团队最后一次失去了两天.通常会听到"我刚刚更新了您的最新更改,您是否可以检查以确保合并中没有任何消失？".我们不再使用Jira,而是在TFS中使用可怕的问题跟踪,导致更多问题.

团队中的一些开发人员已经开始使用git,无论是独立还是git-tfs桥.其他人只是在任何"冒险"活动之前复制源树,例如更新或签入.

无论哪种方式,我都不会推荐给没有经验的团队......