TFS for Java - bad idea?
Asked Answered
S

6

21

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

Slavocracy answered 10/2, 2012 at 17:33 Comment(5)
What IDE are your java developers using? Microsoft ships a plug-in to Eclipse for TFS. There's a free demo available for download so your Java developers can check it out. microsoft.com/visualstudio/en-us/products/2010-editions/…Tressietressure
They use Eclipse. Thanks for the link. I'll check this out.Slavocracy
Considering that you asked this a year ago, I'm wondering if you have a follow up?Burchell
@DustyJ I added one more answer - have the same experience as youAria
We are now 2 years after migrating to TFS. Just upgraded to 2013. The team absolutely love it and can't even think about the old svn days!Slavocracy
I
45

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.

Inchon answered 10/2, 2012 at 19:53 Comment(0)
B
6

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...

Burchell answered 18/12, 2012 at 7:29 Comment(6)
QFT. We have had multiple cases where TFS (or the Eclipse plug-in, who knows) just didn't commit everything to the repository. Client side it claimed that every change was committed, while on the server it wasn't there. That's rather worrying behaviour for a VCS. Also; good luck renaming your package structure with TFS constantly telling you that "At this moment Team Foundation Server cannot delete an empty package(s) remained after renaming.". TFS and the Eclipse plugi-in aren't inherently bad, they just don't work well enough for me to be able to recommend it.Dragon
Is this answer still valid? I'm wondering, since TFS now supports Git.Ji
I no longer use TFS, but I doubt that Microsoft got Git emulation correct on the first try...Burchell
TFS doesn't "emulate" Git at all. It just uses plain old msysGit. By 2017, I think that for all intents and purposes Git has superseded TFSVC as TFS's primary VCS.Natty
FWIW, TFS is not / never has been "top of the line" for ".NET developers". Developers are developers, and TFS/TFVC is a horrible experience. Right now, I've been waiting for ~5min for the merge window to open after getting latest. Before that, I had about 20 error dialogs pop up while getting latest. And this is normal. People, please use Git instead of TFS/TFVC. Please!Meggie
@DustyJ Visual Studio Online / TFS with Git is great. TFVC is the thing to avoid.Meggie
D
4

I like the answer of @Martin_Woodward a lot, but it is too much biased in my opinion, so I add my 2 cents here. We in our company are in a similar situation, and the decision (in my opinion) depends on the context. I can see 3 different situations, and the decisions may be different in each one:

  1. You are mostly developing .NET solutions, and the Java parts are integrated in the .NET solutions.
  2. Your .NET solutions are independent developed from the Java solutions, and they are half .NET, half Java.
  3. Most of your solutions are developed with Java, and only a small percentage is developed with .NET

I would agree with Martin only in the first case. You will gain profit from the common development environment, source code control, build process ... Your Java guys will learn the differences to TFS Source Control (does it have a name??). And your future will look bright ;-)

If your .NET solutions and Java solutions are independent from each other, the only argument to use TFS for developing Java solutions is cost in operation. And you should carefully look at it, if the savings for operating the development environment only TFS will out weight the additional cost of switching your Subversion projects to TFS.

In the last case, it would be an awful decision to switch with a lot of people just to have a common environment to develop. You may integrate Subversion into VisualStudio (using e.g. VisualSVN or other plugins), and you have nearly no invest at all.

The migration of source code including history is normally a pain, and it depends on the source and target if that works well. We have good experiences with CSV and SVN, but no (good) experience with others. But that is normally not a problem, you may use your old SVN repositories (read-only) and just migrate the last milestone. After some time, SVN repos may be let alone ...

Dispend answered 11/2, 2012 at 18:30 Comment(1)
An important thing left out in this answer is that TFS adds a lot more than just source control. The Team Explorer Everywhere also adds work item management, basic issue tracking, and cross project reporting capabilities. Things SVN alone won't provide. I do have to admit that there are open source tools which combined provide a similar feature set, but none I know of provide as broad a feature set as TFS for both Java and .NET development.Atrabilious
A
3

After 1 year working with TFS/Java I completely agree with Dusty J (Yes, TFS/Java is bad) and completely disagree with Martin Woodward about great Microsoft support. Although for my duty as a developer the Eclipse TFS is OK, the problems are for my build/release duties.

First, this Eclipse plugin does not allow creating a branch for several projects at once as in CVS/SVN. One needs to create a branch separately for every project. Then we cannot keep the same project names in the branch – one needs changing a project name and after checking out from the branch to rename to the original name. See also my post How to associate an Eclipse Workspace with TFS workspace?, there is no way to associate an Eclipse workspace with TFS workspace. Thus, the mapping for a local folder cannot be saved; it needs to be done again after opening another Eclipse workspace for branch building. And since the local mapping is the same there is a possibility of erasing a local folder with unsaved work as Dusty J wrote.

This removing local files without warning is a terrible feature of TFS (see the post Why command get from a command line in TFS removes parallel projects?). What Microsoft thinks about the possibility of erasing local files just under regular option "Remove Local Mapping" in Eclipse?

So, despite my effort to learn TFS I still spend 10 times more time for various builds as compared to CVS I used before.

Aria answered 13/2, 2014 at 17:51 Comment(6)
I'm sorry you're frustrated, but I'm not entirely what you're asking for. Certainly you should be able to branch several projects at once. Have you asked a question here or at the MSDN forum? social.msdn.microsoft.com/Forums/vstudio/en-US/home?forum=teeTressietressure
Why are you sure that this is possible with Eclipse plugin? I tried many timesAria
We added branching functionality in Teamprise 2.0 and have tested it extensively; we allow you to branch a very complex workspace mapping. So we'd love to understand your workflow better to understand why the plug-in isn't working for you.Tressietressure
Do I need a new Eclipse Plugin, I have now 12.0.0.201310110941? ThanksAria
No, that version is legit. I think there's a newer version, but it's going to have new features, nothing that solves your complaints. Really, though: I'm very sorry that you've been unhappy for a year. If you open a new question that outlines what you want and the steps you're taking, we'll try to get you there.Tressietressure
Ideally, I would like to select several projects in Eclipse and put them into a separate branch. If I need to work from a branch I simply check out the branch projects from the repository. Usually I do this in another Eclipse workspace (and another folder correspondingly) in order not to mess with the head. Sorry, not clear where and how formulate these requests - where to put a question?Aria
G
0

(Another biased MS employee)

TFS formed a team about 18 months ago to focus solely on making the Java experience great in TFS/Team Services and across all platforms. I am on that team and I think we have made a ton of great progress. I won't disagree that the end to end story was pretty bad when this question was asked, but I think the answer has changed quite a bit in the last year.

My team provides build and deployment tasks for TFS as well the plugins for Eclipse and IntelliJ to make the end to end experience as complete as possible. We are also working hard to make sure we document how to get the best out of TFS if you are a Java developer.

If you want more details, checkout http://java.visualstudio.com.

Thanks, Jason Prickett

Germinant answered 22/8, 2016 at 18:8 Comment(0)
L
-1

Why not use SVN for the .NET projects? Is there any reason for that? There are multiple plugins for SVN in Visual Studio as well as a windows shell extension.

Logic answered 10/2, 2012 at 17:49 Comment(3)
Thanks for the answer Alex. The main reason our .NET teams like the the project management and bug tracking features of TFS. In ALM prospective, it gives us more control and outlook on the projects progress. The second reason is our Java projects are older legacy projects and we know some day we will be 100% .NET. We have a team porting Java to .NET as we speak...Slavocracy
There are open ALM platforms that include Subversion such as CollabNet TeamForge - open.collab.net/products/ctf. This includes Visual Studio and Eclipse clients for issue tracker and Subversion. Also includes support for Git if you want that in the future.Loupgarou
Yes, Microsoft tools are usually pretty powerful tools, if the high cost of investment is not an issue, and as you've seen from Martin's answer there are a lot of good solutions to your problem. Tell us how the migration will work out, and good luck!Logic

© 2022 - 2024 — McMap. All rights reserved.