TFS for Java - bad idea?

Question

We're considering TFS for our .NET based projects and as a task management platform. Some teams develop exclusively in Java and they're quite happy with SVN (Subclipse).

Our managers came up with the following questions:

• Should we migrate the Java teams to TFS as well?
• Does TFS (source control only) handles well Java projects?
• Is it a pain to migrate our Java code base and history from Subclipse to TFS?

Currently we are looking to use TFS as a sole source control platform for maintainability reasons. We would like to avoid having our IT guys supporting multiple systems.

Thanks

Answer 1

Full disclosure, I work on the team that write the Java tooling for TFS so take this answer as appropriately biased :-)

As far as TFS is concerned - all code is created equal. It's just bytes in files that it checks in to version control. Like all SCM systems it doesn't care what language the files are written in.

Microsoft provide a full, rich TFS Plug-in for Eclipse (called Team Explorer Everywhere). This provides full source control, work item tracking, build, sharepoint, reports access etc into TFS from Eclipse based IDE's. It's written in 100% Java and talks directly to the web services exposed by TFS.

In addition we also provide a cross-platform command line client for TFS so that you can talk to TFS from the command line on your operating system of choice (Mac, Linux, Solaris, HP-UX, Aix etc all fully supported).

Finally, if you have tools written in Java that want to talk to TFS then they can make use of the TFS SDK for Java which is the full API that we used to create the Eclipse integration and cross-platform command line client but packaged up with samples and snippets and ready for you to redistribute with your applications.

When it comes to build you have a couple of choices. If you want to stick with your current build server then it is likely that this already supports talking to TFS (all the popular open source build servers do). In addition to that, Microsoft provide the TFS Build Extensions which allow you to run Ant or Maven based builds on the Team Foundation Build server. The build results (along with any warnings or errors) are published back into TFS along with any JUnit test data if you execute JUnit tests as part of your build. Also you get to create and manage the build definitions in the Eclipse IDE and have one place to manage access to them etc.

So - the level of support for Java is very high and Microsoft has shown consistent investment in this area. We recently shipped some TFS 2010 Power Tools for Eclipse and we've also been shipping preview releases of Team Explorer Everywhere 11 alongside Team Foundation Server 11 (we're the same team inside the company).

To import history from SVN, that's the same as importing history from any SCM tool into TFS (or TFS into any SCM tool). You have a couple of options. You can take a snapshot and cut over at a particular point (such as a release) or you can migrate history. To Migrate history from SVN there are some partner solutions available including one from Timely Migration that I've seen a lot of customers have success with.

Hope that helps.

Answer 2

After a year of working on a Java/JVM project using TFS, I would like to dissuade anyone from doing this. While TFS may be considered top-of-the-line for .NET developers, you won't find any Java Developers with any experience with it. There is the plug-in for Eclipse and a port to IntelliJ, but I've had terrible luck with both, though I'm guessing it's mainly because TFS does not work like any other VCS I've used.

On our team, we've estimated a 10-15% overhead due to TFS and complications caused by it. Days of work lost because TFS decided to overwrite files, days of troubleshooting issues caused by incomplete TFS Updates. We have done a branch in 6 months because the entire team lost two days the last time we did. It's common to hear the phrase "I just updated with your latest changes, can you come check to make sure nothing disappeared in the merge?". Instead of using Jira, we're stuck using the terrible issue-tracking in TFS, causing more yet more issues.

Several of the developers on the team have taken to either using git, either standalone or the git-tfs bridge. Others just copy the source tree prior to any 'risky' activities, like updating or checking in.

Either way, I wouldn't recommend it for a team that does not have experience with it...