Reasoning for the use of VCS
It is probably easier to illustrate a sample use case with an example. Suppose two people, A and B are working on an interferometer simulation program. The simulation program has three files, file1, file2 and file3. Initially, exact copies of those files are installed to the computers of A and B.
Now, A started to edit file1 to implement a new function. About the same time, B started to edit file2 to add his own changes to it. If they continue to work like this for a while, they will eventually have two very different sets of files. There may be some inconsistent changes made by them to their own version of the program. After a while, it will become very difficult to merge their works back to a single program.
If they use SVN, the story will be different. They will first set up a repository and store the initial version of the program in it. Before making changes to file1, A will check-out a local copy of the files to his computer from the repository. B will also check-out his copy of the files from the repository. Then they will make changes to their local working-copy of the files. After making a change to file1, A will commit the changes to the repository. The "commit" will propagate the changes made to A's local copy of file1 to the file1 in the repository. SVN automatically records the difference between the original file1 and the updated one (to keep track of the changes). So you can always roll back the file1 to the original version if you want. Before start working on the program, B will first update his local working-copy. When commanded to "update", svn will compare the working-copy and the repository. If it finds updated files in the repository, it will update the working-copy accordingly. Therefore, B can be sure that any changes previously made by A is incorporated in his working-copy. After B edited file2, he will commit the changes to the repository. This change is propagated to A's working-copy when A performs "update" next time.
By making sure to commit and update periodically, the working-copies of A and B are roughly synchronized. Moreover, it is easy to see what changes were made by your colleagues (diffs between versions) with svn, so that you can always be aware of what other people are doing.
Of course, there is no magic behind the svn. With svn, you can still break compatibilities between files, or make the program impossible to compile or run. This can only be avoided by communication between the collaborators. However, svn can in some sense enforce the communication, because if you make a change which break compatibility with other parts of the program, other people will see the problem immediately and complain. When you are working on your own version of the program by yourself, you in general are less careful about making incompatible changes, as it only affects you and you know what you did exactly. However, when working with svn, you are more aware of other people and feel more obliged to inform other people of what kind of changes you want to make. This may slow down the development process a little bit, but in the long run, it may save a lot of time, because your changes are always checked by other people, and it is less likely for you to make stupid mistakes.