What is the SVN version control system?

Choosing the right version control system to work with your files might seem to be a complicated task. To help you select the version control system that will meet your objectives, we suggest that you consider Subversion (SVN). Why is it worth your attention? First, SVN is an open-source and centralized version control system. Due to its more secure centralized approach, it is easier to control the coding process and manage access to modified files. Second, you do not need to have a lot of space to store the files: you can only keep the files to be updated on your local computer and then commit them to the server.

In the article, you can read about how SVN works, what advantages and disadvantages it has, and what basic commands you can execute to work with the files. And to make it easier for you to manage changes that you make and then commit to the SVN repository, you can use dbForge Source Control for SQL Server. In the article, we explain why it is better to use this database change management tool.

Types of version control systems

A version control system manages changes in a file or a set of files and organizes those changes in versions. There are three different types of version control systems:

• Localized, which is deployed on your local computer. It stores file changes, which you made since the previous version, as a patch. Since data is stored locally, you may lose it in case of errors or any corruption.
• Centralized, which maintains a single central repository for versioned files and their change history. Multiple users can have access to files on the server from their local computers and be aware of who checks out the files and what changes apply. However, if the server is down, the changes cannot be pulled or saved and may be lost. Thus, it is recommended that you have a backup.
• Distributed, which allows you to clone a repository along with the full history of changes on your local computers. In case of any issues with the server, you can share your copy of the project version through the remote repository and thus avoid losing any data.

Now that the models are clear, let's explore how SVN, the centralized option, operates in practice.

How SVN works

SVN stands for Subversion. It is a centralized version control system distributed under an open-source Apache license. SVN allows multiple developers to have the current and recent versions of data, such as source files, in sync. It keeps track of every change users make to files. Thus, you can easily restore earlier versions and analyze the history of changes, identify who made file modifications, when, and why. This way, the development is done much faster.

The workflow is the following: you check out a working copy of the files to your local computer. Then, you can make changes to the files in your working copy through an SVN client program that has access to the SVN server and verify that everything works properly. After that, you commit the changes directly to the central server repository. The central server of SVN stores the history of changes to the versioned data in the form of revisions. Thus, each time you update the file, the server creates its new version. If you want to update your local working copy with the latest changes, you need to pull the file from the central server. If you need the older version, you should roll back to the earlier revision.

Inside SSMS, dbForge Source Control standardizes the SVN workflow into four GUI actions. It enables users to:

• Link a database to SVN: Configure the repository once from the Source Control pane.
• Review diffs: Inspect object-level changes visually before committing.
• Commit with context: Enter a message; revisions are logged automatically.
• Audit history and roll back: Navigate prior revisions and revert without manual scripts.

With the lifecycle in view, let's see how to set up SVN version control and perform day-to-day console actions you’ll use to move changes through it.

Setting up an SVN server for SQL projects

To use SVN effectively for SQL Server projects, you first need to set up a central repository. The process differs slightly between Linux and Windows, but the core steps are the same:

1. Install SVN: On Linux, use the sudo apt-get install subversion command. On Windows, install VisualSVN Server, which provides a GUI for setup and management.
2. Create a repository: Run the following command on Linux, or use the VisualSVN interface on Windows:

svnadmin create /path/to/repo

3. Set permissions and access control: Configure user authentication and access rights in the passwd and authz files (Linux), or through VisualSVN's built-in security settings (Windows).
4. Link to dbForge Source Control: In SSMS, open dbForge Source Control, select SVN as your VCS, and connect to the repository. This allows you to commit schema changes, view revision history, and manage versions directly in SSMS.

How to check an SVN version

To find out the version of the SVN server, you can do the following:

• When accessing the server via the browser, switch to the SVN server repository and search for the version in the HTML source code. However, this depends on the server configuration and is often disabled for security reasons.
• When checking the server version by using the SVN client, run svn --version in the terminal:

Basic commands

You can perform operations either through the command-line interface or with the help of an SVN client. Here is the list of some basic SVN commands that help you easily and efficiently cope with data change management.

• svn checkout/svn co URL
  Pulls source data to a local working copy from the repository. URL is a path to the data you want to check out. During checkout, SVN creates a hidden .svn file that contains some repository details.
• svn commit -m "commit reason"
  Saves the changes you have made in the working copy to the repository. In the -m "commit reason" part, you leave your comments explaining the commit.
• svnadmin create
  Creates an empty repository.
• svn list
  Displays all the files in the SVN repository without creating a new working copy.
• svn add
  Adds a new file or directory to the SVN repository. Note that the file will be added after you commit it to the repository.
• svn delete
  Removes the file from the working copy or repository. Note that the file will be deleted from the repository after you have done a commit.
• svn status
  Displays a status of the working copy (modified, added, deleted).
• svn log
  Displays log messages from the repository.
• svn move
  Transfers a file from one directory to another, or renames a file.
• svn update path
  Gets the latest changes from the repository to your working copy. path is a revision with which you want to synchronize your working copy. If you do not specify the revision, the changes will be retrieved from the HEAD revision.
• svn diff
  Displays the differences between two revisions: your working copy and the copy from the central SVN repository.

Now that we have covered the command-line primitives, the following walkthrough shows their equivalents in SSMS using dbForge's guided workflow.

How to manage SQL Server changes with SVN

With dbForge Source Control for SQL Server, you can link a database to an SVN repository and manage schema changes directly inside SSMS.

Step-by-step workflow:

• Link a database to SVN: Connect your SQL Server database to an SVN repository from the dbForge Source Control pane in SSMS.
• Make schema changes: Modify tables, stored procedures, or views in SSMS; changes are detected automatically.
• Commit changes: Review pending objects in Source Control, add a message, and commit to SVN; each commit is logged as a revision.
• Work with versioned scripts: Each commit stores a versioned SQL script; compare revisions to track schema evolution and object history.
• Review history and roll back: Open the History tab to see who changed what and when; revert an object to an earlier revision if needed.

SVN branches and tags explained

Branches and tags in SVN help teams manage development workflows and project milestones. Let's explore what they are and how they work.

Branches

A branch is a copy of the project that lets you work on new features or fixes without touching the main code line (trunk). For example, you might branch off the trunk to redesign a database schema.

To create a branch, run the code below:

svn copy ^/trunk ^/branches/feature-schema-redesign -m "Create schema redesign branch"

To switch to a branch, execute the following code:

svn switch ^/branches/feature-schema-redesign

Tags

A tag marks a specific state of the repository, often used for releases or checkpoints. For instance, you can tag the database at the time of a production deployment.

To create a tag, use the following command:

svn copy ^/trunk ^/tags/release-1.0 -m "Tag release 1.0"

Using branches and tags with dbForge Source Control for SQL Server

When SVN branches or tags are created, dbForge Source Control for SQL Server reflects them in SSMS. This makes it easy to:

• Align schema changes with feature branches.
• Tag and track stable database versions for releases.
• Roll back to a tagged revision if an issue arises after deployment.

How to lock and unlock files

You may encounter a situation when your working copy differs from the one in the SVN server repository. For example, if you did not update your working copy with the latest changes from the SVN server repository and modified the file, you may face a conflict.

However, if the text file, such as a readme file, is outdated, you can merge your local changes with the changes in the repository. In this case, no conflict arises, as your changes will be automatically merged with the latest copy from the repository. If you and another developer modify the same file, you can resolve the conflict manually by comparing the code and applying the required changes.

But if both of you modify the same graphic file, you cannot merge it, and one of you will lose your changes. Instead, you can lock the file.

How does it work? You run a lock command that puts a flag on the file with which you are working. This lock informs that the file is blocked and only you can alter and commit it. Other users won't be able to modify, delete, or commit the file until you unlock it. Still, other users may be unaware of the locked file. Therefore, they should conduct a regular check of the file status.

To lock the file, run svn lock filename where filename is the path to the file you want to lock. If you want to lock the file that has already been locked by another user, you need to run the following command: svn lock --force filename.

To check the status of the file, run svn status. This command will display the statuses of all files in the current directory. For example, A refers to added, M - to modified, L - to locked, C - to conflict, etc.

When you finish working on the file, you can unlock it by running svn unlock filename. After that, other users can start performing some operations on the file. If you want to commit the locked file, you can run the svn unlock --force command.

Sometimes you can get an error message when working with the lock commands: Can't open file 'PATH/TO/YOUR/FILES/.svn/lock': Permission denied. It means that you ran the SVN commands as a root user, which is better to avoid. To resolve the issue, you need to reset file access rights and ownership on all your files in your directory, including the hidden .svn files. To achieve this, execute the commands in the following order:

# specify the path to your project
cd /path_to_your_project

# reset ownership rights
# replace user_and_group with your username and group
sudo find . -exec chown user_and_group {} \;

# reset permissions
# replace file_permissions with your file permissions
sudo find . -exec chmod file_permissions {} \;

# execute the cleanup command to repair your .svn folders
svn cleanup

Can you use SVN for non-code files?

SVN is not limited to source code. It can also version-control documents and binary assets, provided you follow a few best practices.

• Practical examples: Use SVN to track Word documents, Excel spreadsheets, design assets, or images alongside SQL scripts and source code.
• Locking binary files: Binary files cannot be merged, so they must be locked to prevent conflicts:

svn lock design.psd

Best practices for non-text assets:

• Always lock binary files before editing to avoid overwriting other users' changes.
• Store only essential assets to keep the repository lightweight and efficient.
• Write clear commit messages so non-code changes remain as traceable as schema updates.

However, before tying into pipelines or opening a support ticket, confirm the toolchain level on both client and server.

With the workflow and safeguards clear, let's weigh SVN's trade-offs.

Subversion pros and cons

The advantages of Subversion include:

• Free open-source version control system.
• Single server for the repository and its metadata. It allows users to store locally only those files that they want to update and commit them directly to the server.
• History of changes.
• Faster synchronization of differences between the local copy and the one on the central server.

The disadvantages of Subversion are as follows:

• Manual conflict resolution on shared files, which slows teams.
• A requirement for a connection to the central repository to commit, limiting offline work.
• Branches implemented as server-side directories, which can be challenging to manage.
• Higher storage overhead: branch creation duplicates the project tree, especially with large binaries.

Alternatives to SVN for database version control

SVN is a reliable choice for centralized version control, but it is not the only option. Other systems like Git, Mercurial, and TFS are also widely used in database development. Each comes with its own strengths, setup requirements, and integration options for SQL Server.

Benefits of using dbForge Source Control

The market offers plenty of tools to work with changes in the SVN. However, one of the most convenient and efficient tools is dbForge Source Control for SQL Server, a solution that makes database change management easier than ever. With it, you can link your databases to SVN and perform all operations directly inside SSMS:

• Boost developer productivity: Detect, review, and commit schema changes from the Source Control pane in SSMS.
• Simplify teamwork: Coordinate multiple developers with change tracking, object-level diffs, and conflict prompts.
• Automate repeatable tasks: Standardize compare/commit flows and reduce manual scripting during releases.
• Fit into DevOps: Integrate versioning with build/deploy pipelines while keeping SSMS as the primary workspace.
• Manage changes visually: Use a clear UI for pending changes, diffs, and comments instead of ad-hoc scripts.
• Support both development models: Work with shared and dedicated database development models.
• See full history: View a complete revision history for databases and individual objects.

Practical use case

A developer modifies a stored procedure in SSMS. Using dbForge Source Control, the change is committed directly to SVN, automatically logged as a revision, and can be rolled back to an earlier version if needed. This creates a reliable audit trail for every database update.

Development workflows

dbForge supports both:

• Shared model: all developers work on the same database, with changes tracked and committed centrally.
• Dedicated model: each developer works on a local copy, committing changes individually before merging into SVN.

FAQ