Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Coordination
One goal of source code control is to coordinate among programmers.
Alfred decides to change foo.java, and makes a copy from the official store.
Betty decides to change foo.java, and makes a copy.
Alfred makes changes, debugs them, tests them, and then replaces the original copy of foo.java with the new one.
Betty makes changes, debugs them, tests them, and then replaces foo.java, thereby stomping on any changes Alfred has made.
This is a classic transaction problem, as in database scenarios. The simplest way to handle it is for Alfred to leave a note on Betty's desk: "Don't fiddle with foo.java for a while because I'm working on it." This note-on-the-desk version doesn't work so well when one desk is in the United States and the other is in Germany, though email makes a pretty good substitute.
The more programmers on your team, the more likely it is that you need a source code control system such as CVS or Visual SourceSafe. These systems work on a "check out, check in" model, in which you get your copy of the source code to work on not by simply copying it but by requesting a copy from a central server ("check out"). When you're done, you return the changed version to the server ("check in"). CVS monitors when files have been checked out by two different people at the same time, and prevents conflicting versions from being checked back in. You can override that control, but you're taking a risk that your changes won't be compatible with the other changes, and you'll have to go through some effort to put them together.
Almost every source code control system works at the file level. That is, the basic unit of checking in and checking out is one file. This gives you reason to keep your classes (in Java) and your functions (in C) relatively small and functionally separate (orthogonal, to speak geek.)
Some programmers prefer long files so that everything is all in one place, but that tends to hinder collaboration. If one file is a frequent "bone of contention" between programmers working on a project, it may be time to find a way to break that file into separate files.