For those of you who use source control (and it should be everyone), you know the title of this post to be true.  Source control is just a technology, and no technology makes all problems go away.  In my previous post about software builds, I received a comment about locking checkouts and check-in conflicts.  Rob was particularly interested in whether I check in project and solution files.  The answer is YES.  I check in everything.

If you use VSS, you use the check-out/check-in paradigm.  In this paradigm, someone checks out a file, and it is unavailable until they check it in (much like a library book).  VSS does have the option for shared checkouts so that checked out files are locked against change, but most VSS users I know use locking and are afraid of two code files merging.

Subversion, the SCC system I prefer, uses a different paradigm.  To get the latest source, you would check out a repository or a branch of a repository.  The “Check out” step only happens once when setting up the working copy.  You always have the source checked out, but it is never locked.  If you need updated source from a team member’s changes, you issue the “Update” command.  When you are ready to push some of your changes to the SCC server, you issue a “Commit” command.  Every update is a merge from the source of record into your working copy, and it preserves any changes you may have made to a file while retrieving changes to the rest of the file.  Every commit is a merge of your change into the repository.  Every code move is a merge.  No code file is every locked against change, and everyone can work at once.

VSS users may become afraid of making a change to the same lines of code that another is changing.  This is where you have a communication problem.

SCC systems _cannot_ compensate for communication within a software team.  Communication is essential to working as a team, and if someone is doing a major refactoring, he should communicate with the rest of the team that some big changes are coming through the next time they update.  At the end of the day, the team should coordinate commits so that each commit is verified by the automated build before another is allowed.  This keeps you from committing to a broken build.

You may work with a distributed team, and your job is much harder because you don’t have the benefit of others with you in the war room.  You should still be constantly communicating over IM and telephone.  You must overcome that communication barrier.

In software, communication is key.