Source versioning is often neglected in small to medium-sized software projects. I have even seen it neglected in large projects, and the consequences are dire.
This page is created to capture my knowledge on source version control using Subversion.
Introduction
What is Source Version Control
The Wikipedia definition for revision control is as follow:
Revision control (also known as version control, source control or (source) code management (SCM)) is the management of changes to documents, programs, and other information stored as computer files. It is most commonly used in software development, where a team of people may be changing the same files. Changes are usually identified by a number or letter code, termed the “revision number”, “revision level”, or simply “revision”. For example, an initial set of files is “revision 1″. When the first change is made, the resulting set is “revision 2″, and so on. Each revision is associated with a timestamp and the person making the change. Revisions can be compared, restored, and with some types of files, merged.
What is Subversion?
The wikipedia definition of Subversion is as follow:
Subversion (SVN) is a version control system initiated in 1999 by CollabNet Inc. It is used to maintain current and historical versions of files such as source code, web pages, and documentation. Its goal is to be a mostly-compatible successor to the widely used Concurrent Versions System (CVS).
Subversion today
Today, it’s unthinkable for any medium to large sized project to NOT use any versioning control at all. SVN is one of the most versatile and reliable source versioning control out there. If you create a new Google Project, you will get a wiki, a download area, and a subversion repository. A large majority of open source projects uses SVN as a collaboration point.
Subversion is used for the following purpose:
- To keep track of the source history (and provide means to ‘go back in time’ to restore earlier version of files
- As a means to control the files version collectively as a tag / release versions
- As a collaboration point, where multiple developers works on their respective directory, but synchronizes commits and updates against a common/central repository.
- As a means to control release management procedure
The Basics
The repository is the place where the source is stored and baselined. With SVN, there’s only one centralized repository, and all developer work against this centralized repository. In recent times, distributed source versioning system such as mercurial have been gaining popularity – but for this note we shall focus on SVN.
A developer may check out a particular version out of the repository and work on it locally. At this point, any changes the developer make on his local working directory will not affect the files in the repository.
checkout
svn checkout is used to
update
commit
revert
Subversion With Eclipse IDE
I’ve tried a few SVN client, and Eclipse IDE plugin Subclipse is the best client that I have encountered so far. Subclipse provides the most basic source control facilities like commits, update, as well as more advanced one such as synchronizing changes prior to commit or update, delta detection between various version of files or tags, creation and merging of branches, conflict resolution via three-way file comparison, and so on.
Branching and Merging
Guidelines on using branch:
- branch on release initialization
- merge on deployment
Guidelines on merging:
- Merging is ‘picking up a LINE’ and replaying that line on your current working directory