views:

376

answers:

8

I'm and open source and SVN lover. We at the company are at a situation that must decide between SVN or Team Foundation Server. I'm trying to convince others to use SVN because I think TFS is enhanced in large teams. We are just 7 developers and 3 testers. Am I right about this?

+2  A: 

Well, TFS is much more than version control. If you are looking for just version control, TFS is way too expensive. IMHO. I would stick with SVN. However if you are looking for things such as the test suite, issue management, etc, then I would look into TFS.

Dustin Laine
But with SVN you can create tests and with help of other open source projects you can utilize issue management. Why a person should use a huge application like TFS?
afsharm
DaveE
Arguably, an integrated, single-vendor solution may well be easier to manage and even have a lower cost of ownership than cobbling together open source components. Or maybe not. This is something we need to measure, not just toss out conclusions on.
Steven Sudit
Agree with all, I like TFS. I did not at first, but it is groing on me. I am a SVN and a SourceGear fan as well.
Dustin Laine
Interestingly, CodePlex offers an SVN interface to its TFS source control system.
Steven Sudit
Why do you think that TFS is expensive? Is FREE if you have MSDN and $400 for a retail version expensive? I do not think so...Although you are forgiven for not knowing the new pricing as it comes into effect on 16th April.
MrHinsh
Hmmm, I think you are mistaken @MrHinsh. Amazon has TFS 2008 for $2500, and compared to free that is expensive. http://www.amazon.com/Microsoft-Visual-Studio-System-Foundation/dp/B000WM1Z5K. And MSDN is $1000 dollars, so your $400 figure is not accurate.
Dustin Laine
$400 is the approximate cost of a TFS 2008 CAL, if you do not already have a Team Edition of VS or MSDN. It's also the approximate cost of a TFS 2010 Basic server. (There is no TFS 2008 Basic -- closest equivalent is Workgroup Edition, which is free with any MSDN but not available at retail.) I say approximate because the vast vast majority of Microsoft's professional customers are on either a volume license or a subscription plan, both of which provide substantial discounts from retail.
Richard Berg
A: 

I've seen SVN used successfully with very large teams, when backed by things like automated build servers. If you're trying to convince others to go with SVN, you are probably better off just identifying the 3 reasons you love SVN that TFS doesn't have and why you feel those are important, than trying to broadly say one is "more efficient"

Russell Steen
I believe in SVN. But I'm looking for some reasons to show that TFS is something giant application that we don't need all of its features.
afsharm
@afsharm, if you're just going to lie to your boss, you don't need our help.
Steven Sudit
It's not a lie, He wants to use TFS in a small team while in my opinion TFS has too many configurations for a small team. Additionally he thinks with TFS we don't need any maintenance efforts.
afsharm
@afsharm: How small is a small team?
Steven Sudit
I am not sure what is meant by "too many configurations". I stood up a TFS production instance on Friday. Once our admin provided the hardware for me, it took about two hours to get it up and running and usable. Using AD Groups for ease of management of users, etc. I've used and outgrown SVN. TFS supports methodologies not just code. Having an integrated environment for VC, WIT, process, reporting, and builds provided by a single vendor is very attractive. The tight integration with VS is great, too. Moved from SVN to TFS about five years ago and have used it at two companies since.
joseph.ferris
+2  A: 

I'm not sure there's any inherent difference (with respect to team size) between the two. The big differences that I'm aware of are:

  1. TFS provides additional features like bug tracking and "Team Build" besides just source control.
  2. All TFS features are integrated nicely into the Visual Studio IDE.
  3. Licensing costs.
C. Dragon 76
It seems that SVN has a very larger community and this is a gold point for me.
afsharm
Yeah, if you're already experienced with one product or the other, that in itself is a *big* advantage. Especially on a small team. While the basic everyday functionality of most source control systems is pretty easy to learn, the harder stuff (administration, backups, managing rights, branching, etc.) can have a significant learning curve.
C. Dragon 76
In my experience, TFS works for small teams quite well. Then again, so does SVN. As C. Dragon said, the choice comes down more to integration and prior experience.
Steven Sudit
Agree with C. Dragon -- familiarity is huge, especially when you don't have the resources to make someone "the TFS guy" nor participate in the whole Microsoft training / trade show / consultant community. /////// On the flip side, I do think it's quite likely that TFS scales better. Based on what I know about SVN architecture, I highly doubt it could handle the kind of load that large TFS instances do (>1M files in an average workspace).
Richard Berg
A: 

Here is your reason: Microsoft doesn't use TFS on its biggest project; Windows.

ssg
Windows is a unique project, and they've spent decades working on its source control. This is not a valid argument.
Steven Sudit
If you don't think the adoption charts in that blog post are impressive as they stand, then you've obviously never worked in a large diverse enterprise.
Richard Berg
@Steven: Windows is unique in its size that's all. What other unique qualities do you think Windows have from a revision control system point of view? @Richard: I didn't say anything about charts. Would you like to read my statement again? I said Microsoft Windows team didn't adopt it that's all. That says a lot by itself. If you don't think that says anything you're obviously a vegetarian.
ssg
@ssg: Well, let's see, it's the most popular OS for machines used by regular people, it's built on top of 30 years of code and includes functionality that more stripped down OS's, such as Linux, offer as add-ons. It's huge and old and yet new.
Steven Sudit
@Steven: And, how are those points relevant to a revision control software? "I can't use TFS on Windows code, because code is 30 years old". "I can't use TFS on Windows code, because code is popular and used by regular people". None of these make sense. Your only valid point is that the code is huge and I already said that, in my answer, which you downvoted.
ssg
@ssg: It's relevant because the product is large and unique enough to justify its own custom source control system. Changing it to TFS might give some benefits, but perhaps not enough to justify the effort. Oh, and for the record, I did not downvote your answer. Thank you for reminding me: I have now corrected my oversight.
Steven Sudit
@Steven: So I say "Microsoft doesn't use TFS on its biggest project which is not a good sign". And you say "Windows is too big that it's OK that TFS isn't used there". I don't see how this refutes my argument. You are just trying to justify Microsoft's decision with the facts neither you or me have an idea about. I'm taking a fact and saying that it's not a good sign, which is different than taking a sign and trying to mitigate it with no facts whatsoever. And thank you for the extra effort to prove me right about my stereotypical assumptions.
ssg
@ssg: The issue isn't whether Windows is too big for TFS, but whether it makes any sense to convert it over all at once to a retail product, abandoning decades of custom solutions. Thank you for reminding me of Linus Torvald's conclusion: hatred of Microsoft is a disease. http://linuxunited.org/en/115.html
Steven Sudit
@Steven: And as an omniscient authority you inherently know Microsoft's rationale on these decisions. Check your facts; Microsoft has been "customizing" their SCM (licensed Perforce code), since 1999, not for decades. So your assumption on time invested on SCM is also wrong. I don't see how "Microsoft hatred" is part of this conversation. Pointing out facts against a Microsoft product makes me a Microsoft-hater, aka a sick person? What kind of reasoning is that?
ssg
I'm going to go out on a limb here and say that MS did *something* for source control before 1999.
Steven Sudit
For the record, I *do* consider myself an authority on Microsoft's internal SCM/build/deployment/QA/etc infrastructure, having helped migrate some of the divisions now proudly featured in that chart. Can't go into details for obvious reasons, but it shouldn't matter. Suffice to say I've done enough large IT projects outside MS to know that their challenges are not unique. I stand by the assertion that anyone with enterprise experience should have a healthy appreciation for the complex costs/benefits behind such efforts, and would thus never write something as dismissive as this "answer."
Richard Berg
@Steven - the most common system used prior to ~1998 was SLM (aka "Slime"). It was pretty terrible. The migration from it to SourceDepot (aka P4) promised enormous benefits, probably moreso than SD->TFS. Even so, I've heard smart people argue that the migration process was among the top reasons why Windows 2000 shipped 3 years late. No such thing as a free lunch in this biz...
Richard Berg
@Richard: Thanks for injecting some much-needed factuality into this discussion. The two worst things you can do with a source control system are to migrate away from it too soon, or delay migrating away from it too long. Finding the moment when either extreme can be avoided is why we get paychecks.
Steven Sudit
+3  A: 

Why do you think that TFS is a large system?

I have it installed on my Windows 7 laptop using SQL Express and I do not even notice it is there. With TFS2010 you can opt not to install the Sharepoint, Reportign Services adn Analysis services integration from the get go. You can instead just have Version Control , Work Item tracking (Bugs, Tests, Issues, Tasks and User Storys) and automated Build.

In fact I installed and configured all of that in under 20 minutes and on my most recent project it took around 30 minutes to setup a new product with all of those things.

Why would you use TFS?

  1. Cheap (Free to all MSDN Subscribers and $400 retail with 5 users)
  2. Quick to install
  3. Quick to setup
  4. Easy to use
  5. Lots of documentation
  6. Support for everything from a single vendor

If you are then comfortable with what TFS is offering with a Basic install you can then add Lab Management if you want automated enviroment testing or Analysis services if you want more reporting.

MrHinsh
+1  A: 

+2 cents.

TFS not only brings you Source Control + Work Item tracking (Bugs, Tests, Issues, Tasks and User Storys) + automated Build, you also get a VERY BIG AND IMPRESSIVE Analysis Databse in which you can cross information from these different data sources, without extra work. I mean, you can see why a specific build has some bugs, related to the specified files that have benn checked in, related to the tasks/bugs related to the files, related to the user story which is related to the task, etc. Without additional effory you can get a more detailed view of "what's happening" in a development project.

Regards from Spain

El Bruno
+2  A: 

Comparing SVN to TFS is like comparing apples and oranges. SVN is a Revision Control system whilst TFS is an ALM platform like others have already mentioned.

Lets assume that a company chooses for Subversion, CruiseControl.NET, some kind of Agile Project management tool , a bug tracker (Bugtracker.NET, Bugzilla, ...). Let's assume that all the tools that this company chooses is OSS, one would think that it's free, right? Unfortunately, you would still need to start integrating all these tools and that is where the real cost is.

Sure, a platform such as Team Foundation Server comes with a licensing costs and offers what all the previously mentioned OSS tools offers too but already nicely integrated.

So basically if what you want are tools to support your ALM and you are Microsoft-oriented you should seriously consider TFS as an option. Sure as a technical guy it is fun figuring out how to integrate Bugzilla with Subversion and the project management tool, and the spending nights trying to figure out how we export/import all that date into the custom developed reporting tool that has been specially developed for the HR department for the time tracking reports, and so on. You understand what I mean.

In the end the OSS alternative path costs so much more than the TFS path and people just don't like to admit it, on the other hand off course, if all you want is a Revision Control System you don't need TFS. But if that is all you need as a developer, can you call yourself a serious developer? ;-)

Gabriel Lozano-Moran
A: 

If you want to see just how good TFS is - create a project and then try and export it to another TFS system - from what I see you can't!

So every few years you have to throw everythign away and start over again - since in TFS there is no built-in way to export all what you have done. When you build a new system - you cannot move all the history work items etc. only think you can ever do is just move your code MANUALLY to the new system and recreae everything all over again.

Great way to waste a week's worth of work on every project you have to move.

Tom