koobas.hobune.stream
Using Team Foundation Server with Unity3D and MonoDevelop
Does this makes any sense?
Can we have a Version Control System with TFS without replacing MonoDevelop for Visual Studio?
If not, does Visual Studio plays well with Unity and, then, should we replace Mono with it?
For some background, if you wanna know... We use TFS for other projects here at the company and I'm wondering if it will be good to use it for Unity as well or if TFS simply isn't worth it outside Visual Studio and without using all its extra resources. Actually, I'm already trying it, having lots of issues with it and wondering if we should go back to GIT. It was working perfectly fine, but we wanted to unify the VCS for many reasons.
I think it makes a lot of sense, and I'm actually looking into that as well. For the second question:
Does Visual Studio play well with Unity? Absolutely! Actually, I'm even using Visual Studio running in VMWare Fusion for development with Unity on the Mac. There's only one thing that currently doesn't work with Visual Studio: Debugging. So for that purpose, you'll still have to fire up MonoDevelop every once in a while.
Regarding TFS with Unity in general: I haven't tried it, yet, but it should work like any other version control system that's not directly integrated into Unity. When you have TFS Power Tools installed, you can also use the explorer for version control because it comes with a shell extension: Microsoft Visual Studio Power Tools 2010
If you really want to keep on working with MonoDevelop, you might try this: TFS support (plugin, external tool, etc) from within MonoDevelop?, it recommends using SvnBridge ... but obviously, that would reduce TFS to just version control (and you'd lose the project management features which IMHO are what make TFS really interesting).
I still gotta try it more with using Visual Studio ins$$anonymous$$d of $$anonymous$$ono... $$anonymous$$aybe later. Now... I highly advice against Power Tools. It only made things more complicated and I think it's broken somehow. I've also tried $$anonymous$$onoDevelop plugins and SvnBridge, all in vain. I use Visual Studio alone for handling TFS and for nothing else. And keep on using $$anonymous$$ono with Unity.
That's interesting ... what are the advantages you see with using $$anonymous$$onoDevelop?
I still haven't tried using VStudio in place of $$anonymous$$ono, so I can't really say. But I do foresee one advantage in my very specific case because, actually, I've got both GIT and TFS on the same folder and the new $$anonymous$$ono integrates pretty well with GIT.
And, changing a little bit the subject, for the sake of completing the points you brought: As for the debugging with $$anonymous$$ono, I never really used it, though I tried. It's quite buggy and I haven't got many use cases to try it in some situation in which it would worth the trouble.
Yeah, the bugginess was the general impression I had with $$anonymous$$onoDevelop - not only in the area of debugging. But I'm also just not used to $$anonymous$$onoDevelop but very used to Visual Studio, so I'm very interested in how someone co$$anonymous$$g from $$anonymous$$onoDevelop feels about Visual Studio.
Not sure how well VS handles GIT, though ... and especially not sure if VS could handle GIT + TFS at the same time for a project (I guess that's very unlikely).
Try asking me again later this year. $$anonymous$$aybe I'll have tried VS 'till then! ;)
I know this is an old post, but since people will find it via search I wanted to add that with Visual Studio 2012 you can now use GIT as Microsoft has released visual studio extensions for it.
http://visualstudiogallery.msdn.microsoft.com/abafc7d6-dcaa-40f4-8a5e-d6724bdb980c
Sounds very promising... We chose to stay with GIT and $$anonymous$$onoDevelop due to their great integration. $$anonymous$$aybe this could change everything!
This is an old post, but using TFS LOCAL WORKSPACES with the Unity.VS add-in has been pretty easy to setup and work with. The Local workspaces takes care of some of the performance issues, since some of the operations can occur locally without being connected to TFS; in addition it does not use the read-only bit on the files so that issues with files being readonly are also gone.
The only downside I have seen is it requires about 50% more disk space because files in the workspace are cached locally so you can work completely offline and sync with TFS later, this functionality also includes undoing changes.
