Skip to main content
Version: 8.1

Version control using Subversion

Level: beginner

Creatio lets you use different version control systems. This article covers the use of the most popular of them, Subversion (SVN).

Subversion (SVN) is a free and open-source version control system.

The SVN base is a repository that stores data as a hierarchy of files and directories, i. e., a file tree.

You can perform the following actions with the SVN repository:

  • Read data of other Creatio users to which they granted access:

    • Read files of other Creatio users and the directory tree.
    • Read the directory tree.
    • Review previous versions of files and the directory tree.
  • Modify data:

    • Create new directories and files.
    • Rename directories and files.
    • Change file contents.
    • Delete directories and files.
  • Record data to grant access to other Creatio users.

We recommend using the SVN version control system in the following cases:

  • Creatio .NET Framework.

  • Apps where development is done mostly using no-code tools.

  • Creatio in the cloud.

    We recommend using Git for Creatio on-site. Learn more in a separate article: Version control in Git.

Important

Use the SVN version control system to transfer changes only between development environments. Do not use SVN on a pre-production or production environment. This can render Creatio inoperable or decrease its performance.

When using SVN on a pre-production or production environment, Creatio can be rendered inoperable by errors that occur when transferring changes or saving configuration elements. For example, if the package set as current is a package bound to SVN. You can restore the Creatio operability from a database backup. However, you might lose the changes made in Creatio since the last backup.

Also, if you use SVN on a pre-production or production environment, changes might be delivered without previous testing on the development environment, which is strictly forbidden.

Learn more about setting up and working with SVN in the SVN documentation.

Key concepts

Repository is a central database usually located on a file server. Stores versioned files. Can be accessed over various network protocols or from a local drive.

Working copy is a directory on the local machine. The working copy contains a copy of the files as they were in the repository before a user modified them. That way, you can view the exact changes.

Important

Changes are only documented for text files. For binary files, SVN documents only the fact of change.

Revision is the state of the file system tree. A revision saves the entire set of changes to files and directories as a single change.

Change commitment to the file system tree is an atomic operation that lets you commit the revision.

Revisions in the repository can be represented as a series of file system trees, i. e., an array of revision numbers that start from 0 and increase from left to right (see the image below). Each number contains a file system tree as a snapshot of the repository state after a commit.

note

Unlike other version control systems, revision numbers in SVN refer to entire trees, not individual files.

The general procedure work with files in the working copy is as follows:

  1. Retrieve the latest file versions from the repository.
  2. Work with files on a local machine.
  3. Commit files to the repository.

Versioning models

Different developers might use SVN to develop the same functionality in the same file. If the first developer saves changes first and the second developer saves changes a few seconds later, the changes of the second developer overwrite those of the first developer. While these changes will be present in the repository, they will be absent from the latest file revision. To prevent that, use the following versioning models.

  • the “Lock-Modify-Unlock” model
  • the “Copy-Modify-Merge” model

“Lock-Modify-Unlock” model

The repository enables only one user at a time to modify a file. The first user must lock the file before they can modify it. The second user cannot commit the changes until the first user commits the changes to the repository and unlocks the file.

The model has the following special features:

  • Locking can cause administration issues.

    If the first developer forgets to unlock the file, the second developer loses time.

  • Locking can add redundant steps.

    If developers work with non-overlapping parts of the file, a more efficient alternative is working simultaneously and merging the changes.

  • Locking can create a false sense of security.

    Developers might simultaneously work with different files that contain dependent functionality. In this case, each developer locks their file and thinks they begin a safely isolated task. As a result, the developers do not discuss changes in advance. Some of the changes made might be incompatible, which renders the developed solution inoperable.

Use this model if you work with files that cannot be merged. For example, if the repository contains images and users change them simultaneously, these changes cannot be merged.

“Copy-Modify-Merge” model

The client of each user downloads the project from the repository and creates a personal working copy, i. e., a local copy of the files and directories. After that, users modify their personal copies simultaneously. As a result, personal copies are merged into a new, final version. Generally, SVN merges the changes automatically, but the merge needs to be approved.

Overlapping changes made by two users cause a conflict.

To resolve the conflict, the user who committed the files later must take the following steps:

  1. Discuss the changes that caused the conflict with the user who committed the files earlier.
  2. Manually select the changes from the set of conflicting changes to commit.
  3. Commit the merged file to the repository.

The key factor in using this model is the interaction among users.

Manage files in SVN

SVN writes properties of every file to the .svn service directory of the working copy.

The file properties are as follows:

  • Working file revision. The revision number on which the working copy file is based.
  • Date and time of the last update of the local file copy from the repository.

The purpose of properties is to determine the status of the working copy file.

The statuses of the working copy file are as follows:

  • Not modified and not outdated.

    File changes have not been committed to the repository since the working revision. When you try to update or commit a file, SVN takes no action.

  • Modified locally and not outdated.

    File changes have not been committed to the repository since the base file revision. SVN does not update the file. The file is committed to the repository successfully.

  • Not modified and outdated.

    The file in the working copy is unchanged, but it has been changed in the repository. Update the file so that it matches the current public revision. SVN does not commit the file. The file is updated successfully.

  • Modified locally and outdated.

    The file has been changed both in the working copy and the repository. The commit fails. First, update the file by trying to merge the changes published by another developer with local changes. If SVN cannot merge the changes automatically, you must resolve the conflict manually.

Working copy used in Creatio

SVN mode is enabled in Creatio by default. When the file system development mode is disabled, Creatio uses its own working copies of custom packages that have versioning enabled. These working copies are placed in the directory specified in the defPackagesWorkingCopyPath element of the ConnectionStrings.config configuration file.

If the file system development mode is enabled, you can create a working copy manually in the [Path to Creatio]\Terrasoft.WebApp\Terrasoft.Configuration\Pkg\PackageName directory.

To configure SVN operation, change the sourceControlAuthPath setting of the ConnectionStrings.config configuration file. The setting contains the path to the local directory that stores the user authentication data (login and encrypted password) to connect to the SVN repository. The out-of-the-box Creatio SVN client saves the authentication data. We recommend specifying the path to a permanent directory in the sourceControlAuthPath setting. The operating system can clear the temporary directory specified by default.

SVN client

We recommend using the TortoiseSVN client version 1.9 and later to work with SVN in the file system. This client is a Windows shell extension built into the context menu of Windows Explorer. Learn more about using TortoiseSVN in the TortoiseSVN documentation.


See also

Version control in Creatio IDE

Environments

Delivery in Creatio IDE


Resources

Official Subversion (SVN) documentation

TortoiseSVN official website

Official TortoiseSVN documentation