The goal of database source control is to propagate changes from a development environment, to test and production without issues and to fulfill the need to restore a database at any point in time, maintaining an audit trail, and to allow successful team collaboration during the project.
1. Source Control Systems
There are two types of the version control systems (VCS) Centralized version control systems and Distributed version control systems
Centralized version control systems
These systems include Team Foundation Server, Subversion, Perforce, etc. In a centralized version control system all the versioned files are contained in a single central server and all clients that access the VCS check out files from the central server.
Centralized version control systems have been the de facto standard until fairly recently.
The advantage of a centralized version control system is that everyone on the project can see what everyone else is doing. Also it is easier to an administrator to control and administer a centralized version control systems.
The most important downside of the centralized version control systems is the single point of failure that the centralized server represents. If the centralized server goes down during that time nobody can save changes to anything they’re working on. If the hard disk on which a central database is storage becomes corrupted, and a backup doesn’t exist, the team risks losing everything they worked on.
Distributed version control systems
In a distributed version control system such as Git, Mercurial, Plastic SCM, Bazaar, etc. the clients clone the repository and every clone represents a full backup of the repository. If any server crashes any of the cloned repositories can be used to restore it.
Using a local copy of the repository also means that repository operations are faster than in centralized source control systems because they don’t require network calls to a central server.
2. Choosing a Version Control System
When choosing a source control system that’s right for your team, there are some questions to ask yourself:
- Does it fit your development model?
- Is it easy to learn and use?
- How fast is it?
- Is it an open source (free) or it costs (and how much) to purchase and maintain?
We’ll focus on some of the more popular VCSs:
Subversion (SVN)
Subversion is an open source centralized VCS and one the most popular version control systems as it offers easy to understand concepts. SVN is a step up from previous concurrent version systems. Developed as a project of the Apache Software Foundation, SVN is a part of a rich community of developers and users.
Because of its wide use there are a number of clients (integration software) for Subversion for most IDEs, as well as a lot of extension software:
TortoiseSVN – an Apache™ SubversionSVN client, implemented as a free Windows shell extension, and easy for use. Repository commands can be executed from the context menu provided by Tortoise.
Some of the clients for integration within the development environment are: AnkhSVN and VisualSVN for integration with Visual Studio, or some clients for SQL Server Management Studio integration.
For a full list and comparison of SVN clients refer to the following article.
Team Foundation Server (TFS)
Team Foundation Version Control is a centralized version control system and can be used from small to large projects. Team Foundation Server is also a full Application Lifecycle Management suite which differentiate it from other source control systems, e.g. SVN which is a strictly source control system. TFS also allows applying granular permissions and restricted access down to a file level.
TFS offers more features than SVN (in some opinions SVN features are a subset of TFS features). While other VCSs use third party clients to integrate with Visual Studio, TFS has the native integration with Visual Studio.
Git
Git is the rising star of version control systems developed by Linux kernel creator Linus Torvalds. Git is a fast and efficient open -source distributed version control system, so many major open-source projects are using Git to power their repositories. Considered as technically the most powerful source control tool Git is harder to use for a beginner than, for example, SVN. For a more detailed comparison of Git vs SVN refer to the following article.
Mercurial
Mercurial is also an open-source distributed version control system. Designed for larger projects, Mercurial is very fast, as its creators consider performance as the Mercurial most important feature.
Mercurial is a simpler to use than Git with less functions to learn, and with the similar functions to other VCSs.
3. Database source control core concepts
Every source control system includes two main components, a repository and a working folder:
The repository
The repository is the core of every version control system. It stores information in the form of files and directories and all the change histories.
In the following example we will show how to create a local repository files for Git
One way to create Git repository is by installing GitHub:
- Download and install the GitHub for Windows from http://windows.github.com.
-
In the Welcome dialog enter your credentials. If you do not have an account on GitHub select the Skip setup option and open an account later:
-
In the following dialog select the cross in the left upper corner and in the Create dialog enter the name and a local path to a new repository. Select the Create repository option:
-
Select the Publish repository option. Note that at this point you already have to have an account on GitHub. Click Publish:
-
Your repository will be successfully created:
For more information on how to setup a repository for other source control systems, such as Subversion, Mercurial and other options for creating a Git repository refer to this article.
The Working folder
To be able to edit, add, or delete all files and metadata stored in a repository some version control systems require creating a workspace on a local system.
In case of a centralized version control system such as Subversion, Team Foundation Server, etc. a single central repository is hosted on a server and a working copy of the files (the working folder) is placed on the local system. Each user stores in their working folder a copy of part or all files stored in a central repository.
To set up a working folder each developer has to create a regular folder on his computer and perform checkout.
For example, to check out desired version from TFS:
-
In Visual Studio go to File -> Open and select the Open form Source Control option:
-
Under the Team Explorer pane select the Source Control Explorer option:
-
In the Source Control Explorer pane select the desired folder, right click and select the Get Latest Version option from the context menu:
-
In the Map dialog browse to the created working folder on the local machine and click the Map button to create a workspace mapping to a local working folder:
A distributed version control systems such as Git, Mercurial, etc. utilize the local repository that is fully mirrored with the central repository.
After setting up a repository, and in case of a central version control system a working folder, we will explain, in the next article in this series, how to setup source control in a development environment using SQL Server Management Studio, Visual Studio and by using ApexSQL Source Control.
Useful resources:
Version Control Tools
Getting Started – About Version Control
Git in Other Environments – Git in Visual Studio
February 3, 2015
