Why should my team adopt source control? [closed]

Answer 1

Make sure you have buy in for the rest of the team. Maybe you can test your presentation on them? Hopefully, they see the need as well.

Nice to see good practices being initiated from the bottom up. Maybe everyone will be more likely to adopt the practice if it comes from one of their own instead of some management mandate.

Answer 2

So, can you guys tell me why developers MUST use source control?

• It provides one method for an entire team to use; everybody operates under the same 'ground rules'.
• Changes are orderly vs. chaotic, saving development time.
• The ability to track changes promotes accountability and makes it easier to find the right persom to solve problems in the materials maintained.
• A list of exact changes made can be generated quickly and easily, making it easier to advise users of the information on how it has changed from version to version.
• It is easy to 'roll back' to an earlier version of the information, if a serious mistake was made during a change.

Source Control is like insurance! You hope you never need it, but are glad you have it when you do!

Answer 3

Others have mentioned the specific benefits of source control elsewhere, but I wanted to explicitly address the "VSS" portion of the question.

If your boss wants to use a Microsoft tool, Team Foundation Server with Team Suite is a very nice combination. It also has other tools included, such as bug tracking, documents, and reporting capabilities, which makes a nice platform on which to later improve your process. We are quite happy with it where I work, and my coworkers have told me horror stories about VSS.

Keep TFS in mind as a response to the 'Microsoft Tools' question.

Answer 4

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.

Answer 5

Microsoft (MSDN) has a good article on the benefits of source control.
http://msdn.microsoft.com/en-us/library/ms173539.aspx

There are also lots of good questions here on SO as to the pros and cons.
What are your pros and cons of git after having used it?

Subversion is very popular, but Git is going to be the "next big thing" in the source control world.

Answer 6

It seems to me that most people have covered the major feature of source control but one of the biggest positives is skipped over. These are:

Branches

Without a source code repository it is impossible to create branches (or copies/stream/etc.) of your code for particular purposes. Not being able to create and merge branches is one of the biggest things that disqualifies VSS from being a real source code control system. Some of the purposes of a branch include:

Bug Fix

Sometimes you need to resolve a bug and do it in a place away form the mainline or trunk version of your code. This may be to resolve a problem in the testing environment or any number of reasons. If you have a version control tool you should be able to easily make a new branch (something VSS sucks at) to fix the bug and be able to merge it back into the mainline code if necessary

Maintenance Release

This could be much the same as a bug fix but done after code has been released to production. Examples would be for fix packs, service releases, etc. Again, you want to be able to merge the changes back into the trunk if necessary

New Feature

Sometimes you need to start development of a new version while maintaining your current code. For example you release and maintain v1.0 but need to start work on v2.0 while maintaining v1.0. Branches help resolve this situation

Tagging/Labeling

Another thing source code control systems do is make snapshots of the source code at a particular point in time. These are called labels in VSS, tags in subversion, etc. By creating these on a regular basis and linking them to some substantial milestone in your project it then becomes possible to determine what exactly has changed in your code between releases. This can be important for auditors but also in tracking down the source/scope of an issue. VSS also gets a fail here because VSS only versions the files, not directories. This means it is impossible to re-create a previous version of the system if you rename/move/delete files or directories in the repository (something that happens a lot if you refactor). Good source code control systems like Subversion do just this.