Why should my team adopt source control? [closed]

Question

I have the opportunity to give a formal presentation to my boss about anything that benefits the company. My idea is to adopt source control in my workplace. I have been using Mercurial to manage my own project at work, but the rest of the team does not have a formal source control system in place. Unfortunately, I'm not very good at presenting ideas.

So, can you guys tell me why developers MUST use source control? Additionally, why would you choose any tool except Visual SourceSafe? I don't have experience using VSS, but he is likely to ask why we wouldn't just use Microsoft's tools.

I want to hear opinions from the many smart programmers here! My preferred options are SVN or mercurial. Both seem to have good support for their Windows versions, and both are less archaic than CVS. Also, as a self-declared open source disciple, I would prefer to suggest an open-source tool. :)

Thank you!

Edit: To make it short, generally, current practice for other developers is copying folder, tag with date and maybe record on their own. You get the picture. What if my boss says "if it works, why fix it?"

Answer 1

Let's compare two examples, one development environment that uses source control, and one that doesn't.

• A: Does Use
• B: Does not Use

Scenario 1: A project is requested, completed, and rolled out

A + B) Programmers develop the project internally, when it's completed, push it out to testing, and then deliver to the client (whoever that may be)

Not much difference, in the big picture

Scenario 2: After a project is released, the client decides that they don't want feature X

A + B) Developers remove the code that the client doesn't want, test, and deliver.

Again, not much difference.

Scenario 3: Two weeks later, the client decides that they actually DO want feature X

A) Developers reintegrate the code they took out in 2 back into the normal development tree, test, and deliver.

B) The developers search for the old code on their personal machines, the file server, and backups. If they find the code, they must manually reinsert each file. If they do not, they probably have to recode that entire feature.

It's easy to get old code that you took out for one reason or another

Scenario 4: There's a strange bug in the system where a function is supposed to return a boolean result, but always returns false. It wasn't like that two weeks ago.

A) Developers examine all the old versions of the software, and figure out that a return false directive isn't in the proper scope - it's executing inside a loop instead of outside.

B) Developers spend weeks trying to figure out what the problem is. Eventually, they notice the return on the wrong line, and fix it. Not having source control means they had to examine each and every file that was executed, rather than finding the differences from when it was working and now.

Scenario 5: Someone breaks the build. It gets past testing and is only noticed weeks later.

A) The team examines the commit history, finds out who broke the build, makes that person fix it and buy the team dinner.

B) The team has to go back through the entire project to find the error, but can't figure out who put that code in. Developers blame each other, and the team dynamic fails.

It's easy to see who committed what, when, and why.