Okay, you clearly reserve the right to be as arrogantly dismissive about anyone you please. That's your problem mainly, not mine. I hope the questioner wasn't in the least bit sensitive to your reply.

What are you suggesting - that the acceptable base level of knowledge is your own? Anyone who knows less is somehow deficient, stupid or both? It's a perfectly legitimate question from someone who does not know the answer. That's why people ask questions - so they can learn from people who know a little more. Please be a bit more respectful towards those whose knowledge is different to yours.

PMFBI but I can offer some thoughts as one who manages a small development team, and has used TFS and VSS for several years. We use VS2008 Team System for developing and maintaining a fairly large project (>1million lines of C# code) and VSS for maintaining 'legacy' projects, because that's where they started off. TFS brings much more than source control. On that feature alone it is far superior to VSS (I can't speak for CVS, SVN etc because I haven't used them). In my experience VSS is fine for smaller projects, and where you can ensure that only one developer at a time ever works on a file. With a big project that is often inconvenient and not easy to regulate (and why should you have to?) and TFS's far superior checkin/merge facility helps manage that relatively safely. Given the chance, of the two I would use TFS source control for any non-trivial project employing more than one developer. TFS also brings programmed testing (MSTest unit testing and we also use Selenium), test code-coverage, integrated bug and task tracking, integration with Sharepoint for project documentation control and publishing, and the biggie for me is automated builds. It took us a while to get to where we are today, but I wouldn't be without our CI and nightly build/test/document process. Several times a day and every morning I get an email confirming that all is well, or early warning that something has unexpectedly broken. It's not perfect because you can never have enough tests, but I sleep much better at night as a result. :-) That is not to say that TFS and VS20008 are without their problems. Check-in merges (and branch merges) can get confused and you have to keep your eye on the ball when you do it, but you do get the option to select individual differences if you want complete control. I have found that frequent 'gets' to keep the local copy up to date together with frequent check-ins of changes is a good way to proceed with multiple developers on the project. In other words don't let server and local code drift too far apart, to keep the risk small. The bug/task tracking facilities could be usefully improved (reporting, especially, is a bit clunky - was it designed by the office junior?). VS2008 itself struggles with largish applications and can often 'lose' the various tools such as call-stack, watch windows etc, which for no apparent reason will be blank panes. Frequent restarts of VS2008 are essential, we find, to correct this. It seems to be a memory thing, and we are at the 4Gb limit already on our workstat