TFS, Zero Friction and living in an imperfect world
Roy responded to my post about disliking TFS:
I think that Oren is making one big mistake: he's throwing the baby out with the bath water. Just because the source control is not as zero-friction as some open source alternatives, does not mean that TFS is not a valuable suite of tools, with more added value than most open source tools that I know of.
[List of advantages that TFS has snipped, will cover them later]
I mean, Oren, c’mon! You don’t like a part of a part of team system – the source control aspect is not perfect for you, but what alternative do you have for a suite of tools that works together so powerfully?
First of all, I am grateful that I am only making one big mistake :-) That said, I don't really have an issue with the rest of TFS, but the problem is that without the source control integration, it is losing quite a bit of its charm. The source control is the most visible and annoying part of TFS, I would love to give it a short with SVN integration, but I don't really see it coming.
Roy goes on to list a few points, which I would get to cover:
Just about any bug tracker has this ability, it is not unique for TFS by eany means. Usually it is a matter of a few config options for SVN and a post-commit hook.
This is nice, but it won't work with anything other SCM, so that it not very good. I can get that with Trac as well, so that is not something that really bothers me.
Bug, not a feature. You can't move the folder around, you have cruft left over in your system, deleting the folder won't rid of the remains, etc. Beside, what is the problem with "MyProd\trunk", "MyProd\Branch-1.0", etc?
All of which are nice, but by no mean unique or even very impressive on their on.
Actually, no, I don't. And I flat out refuse to suffer the initial pain for the promised land. Feel free to call me heretic.
The promise of TFS is that you get everything integrated, in one package. The problem of TFS is that you get everything integrated, in one package. I actually like the work items, and if I could get it outside of VS (don't your dare make the IDE any slower), I would like it better. The problem is that I can get as much and more from freely available projects, that works in zero friction.
And you know what, I can get them to work together in the same time it takes to setup TFS.
Comments
"And you know what, I can get them to work together in the same time it takes to setup TFS."
Bravo!!!
Bravo!!!
"Just about any bug tracker has this ability, it is not unique for TFS by eany means. Usually it is a matter of a few config options for SVN and a post-commit hook."
Can you write more specific details on that?
Adi,
Here is an article that talks about how to do it for FogBugz ,but the general idea is the same anywhere.
http://www.fogcreek.com/FogBugz/docs/40/Articles/SourceControl/TortoiseSVN.html
TFS is some really cool stuff. If you want to talk features I'm a big fan of ClearCase and their "streaming" workflow concept (if you can afford it)
Thing is, I've always considered the OSS development to be different than your common in-house full-time team; theres more flux. It varies in things like people joining and leaving the project and contribution frequencies.
I've never managed an OSS project, but the few Ive contributed to always involved subversion or cvs. They're not perfect, but theyre pretty universally understood, which is important when your contributors are a diverse bunch of people.
Pete's got a good point. I'll add that the average .Net developer is not working in an OSS project and is not familiar with anything other than VSS, and it's not all that uncommon to find places that do not use any SCM tool at all (iiirrc!). These developers would benefit a lot from a tool that integrates directly in the IDE, where they don't even need to think too much about source control. The IDE becomes the project collaboration portal.
I have not used the TFS stuff yet, and probably won't for a good time because of it's unreasonable pricing, but I think it would be less complicated for me and my team mates than training everybody in the OSS stack.
Interesting point, but I think that more .NET developers need to look outside of the world Microsoft has built for them. When it comes to source control, someone has to think about it. Sometimes convenience constrains your freedom. I heard that some shops look for a developer to have worked on an open source project, and that's probably a good idea for most developers to do. Concerning the IDE as the collaboration portal, I like that Idea. There was a Dr. Dobbs article on that (I think there is an Eclipse project doing that now). Right now I'm handling the source control on my team, and I plan to put together a few webcasts on our SCM from and admin and user perspective. Teach once, train everywhere.
I would love for someone to write up some detailed how to posts about how to set up on an open source stack to allow people to get away from TFS.
A'braham, what SCM are you using?
I am not fond of IDE as portal, it slows down core activities, like writing code
Brian,
There is such a guide here:
http://analystdeveloper.com/blogs/gurkaneng/archive/2005/09/20/1465.aspx
I think that the approach he takes is more complex than necessary, but he took the time to write a tutorial and I didn't, so I don't have much to say.
Pete,
I would like to hear about ClearCase's features. Can you expand on that?
" Pete's got a good point. I'll add that the average .Net developer is not working in an OSS project "
People are getting mixed up with 'developing an OSS project' and 'developing using an OS toolset'.
Comment preview