Page 176 -

Haunted by Ghosts of Old Problems
Many programming teams use a shared folder to store source code. Even though they are
generally diligent about making backups, and everyone is careful about maintaining the
integrity of the code, mistakes sometimes slip through. Despite their best efforts, the team
finds that new code seems to disappear with some regularity, while defects that were fixed
months ago mysteriously resurface.

At first, the problems happened because one programmer would overwrite another’s
changes. One programmer would copy the code to his hard drive to work on it. While he
was working on his copy of the code, a second programmer would copy it to her drive. The
first programmer would copy his changes back to the shared folder. But when the second
programmer copied her changes back, it would overwrite the changes made by the first pro-
grammer. This caused problems that were difficult to track down; the first programmer did
not realize that his code was no longer in the folder (and neither did anyone else).
This problem seemed to get steadily worse as the code base grew. After the team had to
redo a week’s worth of work because an entire feature was overwritten, they were moti-
vated to search for better solutions. The first solution they tried was creating a “checkout”
folder underneath the source code folder. When a programmer needed to work on a file,
he first moved it to the checkout folder, and then copied it to his local hard drive. Nobody
would work on the file until it was “checked in” by copying it back to the shared folder
and removing the old version from the checkout folder. But this still caused problems—
occasionally someone would accidentally copy an old version of a previously checked-out
file into the shared folder. Nobody would know that it happened until a client complained
about the reappearance of an old bug that had been fixed months earlier. The checkout
folder “solution” was not good enough.

The team eventually put in place version control software, which put the entire source
code into a repository. They chose one that was made by the same vendor as their other
programming tools, because it was included and installed automatically. The software
forced programmers to check out the code before they could alter it and update it back in
the repository, and it locked any checked-out files so that they could not be altered until
they were checked back in by the person who checked them out. This was definitely bet-
ter than a shared folder, but it still caused problems. People would constantly complain of
leaving code checked out on their office machines, only to find that they couldn’t edit
important files when working from home. Occasionally, someone would go on vacation
with an entire project checked out, and nobody could figure out which files she intended
to check back in. And, worst of all, there were some files that everyone needed to alter all
the time. Since only one person could check them out at a time, the programmers were
constantly waiting for each other to finish their tasks. The integrity of their code seemed
safer, but it came at the cost of schedule delays.
Had this team gone with a version control system like Subversion, they could have prevented
all of these problems. With Subversion, a programmer can update any file at any time, no
matter how many people are working on the project. By being forced to resolve conflicts in
the latest version of the code before committing any changes, he can prevent old code from

168 CHAPTER SEVEN