All software development projects should use a version control system (VCS) for tracking and coordinating changes to code files and other project artifacts. The size of the project team doesn't matter as even a single developer benefits from using version control. If you are still using ZIP files to track changes to your source, you should reconsider.
A VCS helps a team coordinate changes to source code and other artifacts during development. If a developer tries to commit changes without updating to the latest version in the repository, the VCS will require the developer to update before committing. This will give the developer a chance to resolve any conflicts that may be present. The VCS also prevents one developer from accidentally overwriting the changes made by another developer.
A VCS also acts as a safety net for developers. If a developer makes a change that breaks the application, the change can easily be reverted by rolling back to a build with the latest known good state in the repository. Even if the change has been committed to the repository, it is possible to revert the change. Modern version control systems support branching, merging, and diffing. (For definitions of these and other terms, please take a look at our Glossary.) They can answer questions such as who last changed this code, what changes were made, and which other files were modified at the same time. They prevent developers from accidentally overwriting other changes either via edit/merge or a pessimistic locking (also known as checkout) mechanism. Although it sounds dangerous at first glance, edit/merge causes less friction on a development team and works better in practice than pessimistic locking. In most cases, merges happen automatically because developers are working on different parts of a code file. If developers happen to be working on the same part of the codebase, they should probably be coordinating their efforts somewhere other than the VCS.
There are many modern version control systems available today. For open source projects, the most popular—and free—choice is Subversion (SVN) and it is supported by most open source project host sites, such as SourceForge, Google Code, and CodePlex. (CodePlex actually uses Microsoft Team Foundation Server for source control, but hosts SvnBridge, which allows Subversion clients to talk to Team Foundation Server.) In corporate environments, teams often install these same version control systems, such as Subversion (SVN) or Team Foundation Server , behind the firewall.
The ScrewTurn Wiki project manages its source code using Subversion. If you want to get started with Subversion, I would recommend downloading TortoiseSVN (http://tortoisesvn.net), which is a Windows Explorer Shell Extension and provides context menus for source control operations. TortoiseSVN will also optionally install the command line tools, which allow you to use Subversion from cmd.exe or PowerShell. Let's take a quick tour of Subversion and TortoiseSVN ( see Figures 2 and 3):
Figure 2 TortoiseSVN File Manager View Showing Overlay Icons
You will notice the icon overlays in Figure 2, which is TortoiseSVN indicating the current status of a file/directory. (Green check = no pending changes; red exclamation = pending changes; question mark = not versioned; grey dash = ignored file) If you right click on a file/directory, as shown in Figure 3, you can see the TortoiseSVN context menu appear.
Figure 3 Context Menus for Source Control Operations
branch: A temporary development line in a VCS repository. Often used while creating a patch, stabilizing a release (while development on the trunk continues), or experimenting with a new (and disruptive) feature.
changeset: Combined set of changes that should be atomically committed to a repository.
commit: Send a changeset to the VCS repository.
diff: Changes made to a file.
merge: Integrating multiple changes into a working copy. The changes can be from a different developer working on the trunk or from another branch.
patch: Changeset expressed as a single file that can be electronically sent to another developer.
tag: An important milestone in a VCS repository, such as a publicly released version (alpha, beta, full release, or patch). Similar in concept to labels in VSS.
trunk: The main development line in a VCS repository.
update: Retrieve any changes made to the trunk (or branch) since last update.
working copy: Local copy of a project checked out from a VCS repository.
Other videos from this article