A Version Control System (VCS), also known as a Revision Control System, is software that manages changes to collections of files and directories. While a VCS is useful for managing changes to many types of files, this software is particularly useful for programmers to save files for the source code of computer programs. A VCS keeps track of all of the changes that occur in each revision of the file, the person who made the changes, and the reason behind the modification. Changes are usually identified by an incrementing number (also known as revision number) or letter code, and reflect the content of the files at a specific point in time.
Why is there a need to use a VCS when you can simply save the files in a different filename in one folder? Unlike your usual multiple file saving process, a VCS does not store the full copies of each revision. Instead, it stores only the changes that happen in each revision. That saves a lot of disk space, and also removes the need for the user to manage the naming of the revisions manually. Hence, a VCS is particularly useful for large, fast-changing projects with multiple authors who all need to track and coordinate all changes in each version.
When the most recent version of the file is modified or corrupted, a VCS makes it easy to go back to the previous revision and start again. Also, programmers use the VCS to compare the different versions of their software. By comparing the different versions, they can determine when bugs were introduced and also when were they fixed. Any problems that may arise from a change may be addressed by reviewing the revision, noting who made the change, and the reason behind the change.
Tracking of different versions is also necessary in establishing precedence. Because a VCS keeps track of the person who made changes to the file, it can provide necessary data to solve a dispute regarding ownership of code or ideas.
Version control systems are especially useful for collaborative work. Multiple users can edit the files at one time, without affecting each other’s changes. When they have finished working with a file, they can then decide to merge their versions as one. When two users independently change the same part in a file, they are automatically flagged when the files are merged. Hence, they are still responsible for tracking if the final version is correct.
Version Control Systems can be provided using software installed in-house, or can be accessed via an online version control system provider. Online VCS systems also provide additional functionality, such as bug tracking, archiving, and user management. They are often used for projects that do not have the resources yet to maintain their own server for version control, and also for projects that wish to benefit from the ease of use and additional redundancy provided by an online system.
Concurrent Versioning System (CVS) used to be the most widely used version control system. However, Subversion and Git have long since overtaken it, and are now the most commonly used systems for open source projects. The basic capabilities of these systems in some ways are quite similar to CVS, but they offer much greater functionality.
Some version control systems, like CVS and SVN, have centralized repositories. This works by setting up a single repository which acts as the central store of the system. The repository usually stores information in a hierarchy of files and directories. Check-outs and check-ins of files are done with reference to this central repository. Multiple clients can then connect to the repository and commit changes. Normally, they can only see the latest version of the files. However, they can also review the change history and restore previous versions using VCS tools.
Alternatively, in a distributed VCS like Git or Mercurial, many repositories may be used and no single repository is authoritative. Files can be checked out and checked into any repository. When a file is checked into a different repository, it is integrated as a merge or patch. The responsibility then falls on the users themselves to determine which repository is authoritative.
Ultimately, Version Control Systems have been widely studied and applied in the software engineering community for a long time. These systems are being continually developed and improved to best meet the needs of both small local teams and large distributed teams. A VCS is now considered an essential component of any modern software development process.
Many readers may have heard of the phrase “SVN repository”, but may be unsure exactly what it is. Maybe you have a bit of an idea, but don’t know where or why you would need to use one. This post explains in straightforward terms what is a SVN repository, and gives you a basic understanding of how it works and when and why you should use one.
SVN is a shorthand abbreviation of the name “Subversion”. For those who have not heard of it, Subversion is a powerful open-source version control system that is typically used to manage the collections of files that make up software projects. However, a SVN repository it may actually be used for managing any collection of files that are changed or modified over time.
Subversion was initially developed by CollabNet as an alternative to the earlier CVS version control system, which suffered a number of limitations, such as being unable to move or rename files. These days Subversion is actively developed and maintained by the Apache Software Foundation and you can download SVN for most platforms for free.
The SVN moniker itself actually comes from the name of the command that is typed when accessing SVN repositories via the command-line of a computer, hence it is common practice to use the terms ‘svn’ and ‘subversion’ interchangeably.
In simple terms, a SVN repository (or Subversion repository) is a collection of files and directories, bundled together in a special database that also records a complete history of all the changes that have ever been made to these files.
Conceptually, a SVN repository is similar to a folder or directory on your computer that may contain a collection of assorted, but related, files and directories. In fact, a SVN repository is typically used to store all the files and directories that make up a single project, or perhaps even a collection of interrelated projects.
However unlike a normal folder on your computer that stores only the most recent copy of a collection of files, a SVN repository also stores the history of those files.
One way to think of a SVN repository is by imagining a series of snapshots, called revisions, that record copies of all the files and directories that make up a project at specific points in time. However instead of storing full copies of each revision of every file (which would very quickly require a huge amount of disk space!), a SVN repository only records the changes or differences between files at each revision. These differences are known as a changeset.
A SVN changeset consists of a description of all the additions, modifications and deletions to files within the project required to go from one revision to the next, along with a human-friendly text description that reports the nature of the changes. The collection of all changesets in a project is what makes up a SVN repository.
By drawing on this database of changesets, the Subversion tools are able to recreate exactly any revision of any file in the SVN repository, at any point in time. Not only that, it can do so by using far less disk space than would be required if full copies of each of the file revisions were stored instead!
By storing a complete history of every change ever made within a project, it is possible to use a SVN repository to do many things that would be difficult or impossible to do with only copies of the project files alone.
To get started using Subversion, you first need to have a SVN server to host the repository. There are several ways to do this, depending on your technical knowhow and the benefits you wish to achieve by using it. For example, you can:
Whatever solution you choose, once you start using Subversion the power of a SVN repository becomes apparent very quickly. Over time you will discover more and more ways that you can benefit from version control, and eventually you will begin to wonder how you lived without it!
What uses have you found for your SVN repository?
