How to convince my colleagues to use TFS instead of VSS 6.0?

Question

We currently do C# and WPF programming. I've a really hard time with our source control (Visual Source Safe 6.0). My colleague are persuaded that we have all the features we need and TFS wouldn't help us more than old VSS 6.0 does (just fancy features, you know, nothing a real man needs...).

In my current situation, we are actually building (everybody) and checking in the compiled assemblies of our ~20 sub projects and somebody takes ~2 hours to get make a build every 2 weeks. We work with the SCRUM method. Also, our source control leads to repeating problems, like when updating the satellite assemblies when the root project get some update (e.g. our WPF Control provider, Actipro). My colleagues now seem to tend to solve these problems by trying to automate some stuff with scripts and workarounds.

What would really be helpful is a good web source which explains the whole branching, changeset and etc. stuff to somebody who doesn't know anything else than VSS 6.0. And possibly in a short time (it's about my boss, after all).

I already confronted my colleagues, but I cannot convince them (I'm the youngest one in the job here). And please tell me if you think I'm really wrong about TFS being a huge gain in our situation.

P.S.: I know TFS is SourceSafe under the hood, but it is way better. At least we have changesets, not labels, which solves 95% of our problems.

Answer 1

I suggest that researching misapprehensions like 'TFS is SourceSafe under the hood' would be a good start towards raising your credibility with the rest of the team.

Personally I would wait until VSS loses a great chunk of your source code and then suggest an alternative. This doesn't tend to be a very long wait if there are several of you using it.

Answer 2

SourceSafe was built for the development process as it was in the early 90s. Smaller less complicated projects, with all developers on a small lan. SourceSafe is being phased out and in about 9 months time will no longer be supported by Microsoft (unless you're willing to pay for extended support). I'd thought those arguments would be better suited for a manager than to technical details about changesets etc.

This Infoworld article discuess this: Microsoft looks to move SourceSafe users to newer technology

There's so many blogs/articles about the problems with SourceSafe, here's one by Jeff: Source Control: Anything But SourceSafe

And as Will said, TFS is not built on SourceSafe except that I think some of the developers who wrote SourceSafe might have also been involved in writing TFS.

Answer 3

Starting with TFS 2010, it becomes a no-brainer for even small development groups to use TFS. With 2005 and 2008, the requirement that it be installed on a server-class operating system, and the complexities around the install were a serious hurdle to overcome. TFS 2010 has eliminated all of that, providing a wizard-based install and support for Windows 7 installations.

Regarding branching... The TFS Rangers have come up with some branching guidance. If they're looking for a simple explanation of branching, there are probably some good ones out there for googling, but I explain it like this. This is technically inaccurate, but the concept is sound:

When we branch, we create a copy of the source code we can work on. This copy is isolated from the Trunk, and we all make changes in this copy. This keeps the trunk nice and clean, and we will always know that the trunk has a good copy of the source code.

When we have adequately tested our copy, we move it to the trunk by "merging" it with the code that's already there. In a simple operation, where we only have one branch of our trunk, this is easy. In some operations, there might be one branch per feature being worked on, or a branch per release, or a branch per production bug that all get merged back into the trunk. When we merge our changes to the trunk, we make sure that our changes are successfully intermingled with other peoples changes.