Introduction

Subversion (SVN) is a centralized system designed for collaborative work. It is based on a repository that contains data in form of a “tree” hierarchy of files and folders. Users can connect to the repository to browse, view or modify files. Their modifications are available to all other users, and vice versa.

All modifications are documented in SVN, including the information about added, deleted, and moved files and folders. Users can access SVN files and folders at any given moment. Additionally, they can view all other versions of all files and folders.

Learn more about configuring and using Subversion in this article.

General outline:

Repository – a central database, usually located on a file server that contains versioned files with their full history. A repository can be accessed through various network protocols or from a local disk.

Working copy – a folder located on the developer’s computer. A developer can get the latest version of the files from the repository, work with them locally, and commit these files back to the repository when they are done. A working copy does not include the project’s history, but does contain the copies of files that were located in the repository prior to any changes made by the developer. This enables complete visibility over any changes made to the files.

Revision – a documented state of the file hierarchy. In the repository, each commit is treated as an atomic transaction. Developers can modify several files, create, delete, rename and copy files and folders, and commit the entire set of changes as a single “revision”.

In SVN, all revisions are stored in form of file system “trees” - an array of revision numbers starting with 0 and “growing” from left to right (Fig. 1). Each number corresponds to a file system tree. And each tree is a "snapshot" of the storage state after each commit.

Fig. 1. Revisions in the repository

Versioning models

File-sharing problems

While working in SVN, there may be a problem where two (or more) developers are using the same file to implement different functionality. In this case, if one of the developers commits their changes a few seconds before the other, their changes may be overwritten. And while the system documents all changes, their work may still be lost in the latest version of the file, if the other developer accidentally overwrites the same file.

The following versioning models are used to avoid such problems:

• The “Lock-Modify-Unlock” solution
• The “Copy-Modify-Merge” solution

The “Lock-Modify-Unlock” solution

This versioning model only enables a single user to modify a specified file. A user may “block” the file for all other users, and they will not be able to commit their changes until the lock is released.

Disadvantages:

• Locking may cause administrative problems, e.g. when the first developer locks a file and forgets to release the lock.
• Locking may cause unnecessary serialization. If the developers are working on two separate parts of the same document which do not overlap (e.g., the beginning and the end), the changes can be properly merged together if the file is not locked.
• Locking may create a false sense of security. Two separate files that depend on each other may be locked by two different developers, which means the changes made to each locked file are semantically incompatible, but the two developers may think they are beginning a safe, insulated task. Thus, this model inhibits the two developers from discussing their incompatible changes early on.

This model is more appropriate when the two separate files can not be merged. For example, if two users are editing an image at the same time, they will not be able to merge their changes.

The “Copy-Modify-Merge” solution

In this model, each user's client reads the repository and creates a personal working copy of the file or project. Users then work in parallel, modifying their private copies. Finally, the private copies are merged together into a new, final version. The version control system often assists with the merging, but the user is responsible for making it happen correctly.

A conflict will happen if the changes overlap when two users work on the same file simultaneously. In this case, the user who commits the changes should select the necessary revision from the list of files in a conflict state. Upon resolving the conflict, the merged file can be committed to the repository.

The chance of semantic and syntactic conflicts increases if there is no communication between users.

Determining the state of the working copy file

Subversion records information about the following properties in the .svn service folder of a working copy for each file:

• the revision, which the file in the working copy is based on (working revision of the file)
• date and time of the latest file update from the repository

Based on this information, Subversion can determine the state of the working copy file:

1. Not modified and not outdated. Not modified in the working copy. The repository did not document any changes to this file since its working revision. The update or the commit procedures will not be executed.
2. Modified locally and not outdated. Modified in the working copy. The repository did not document any changes to this file since its base revision. The update will not be executed. The system will commit the changes successfully.
3. Not modified, outdated. Not modified in the working folder, modified in the repository. The file must be updated to match the current public revision. The update will not be executed. The system will commit the changes successfully.
4. Modified locally and outdated. Modified in the working folder and in the repository. The commit procedure will fail. The file must first be updated by attempting to merge the changes published by another developer with the local changes. The user must resolve the conflict if Subversion can not merge the files.

Working copy used in bpm’online

If the file system development mode is enabled, bpm’online will use a custom working copy of each user package with connected versioning. These working copies are located in the folder specified in the defPackagesWorkingCopyPath element of the ConnectionStrings.config configuration file (see “How to deploy bpm'online on-site”).

If the file system development mode is enabled, the working copy can be created manually in the [Installed application path]\Terrasoft.WebApp\Terrasoft.Configuration\Pkg\[Package name] folder (see: “Creating a package in the file system development mode”).

Using an application to work in SVN

We recommend using TortoiseSVN (version 1.8 and higher) to work with Subversion (SVN) in the file system. Once installed, the application will be built in in the Windows UI. Learn more about TortoiseSVN in this article.