Synchronization Models, also known as Configuration Management Models (Feiler, 1991), describe methods to enable revision control through allowing simultaneous, concurrent changes to individual files.
Feiler (1991) reports on four different synchronization models, shortly described below.
In the check-out/check-in model, files are stored individually in a repository from which they are checked out whenever the files are accessed, and checked in when they have changed. This repository can store multiple versions of the files. Because these files can be documentation or source code, but can also be a collection of files, the term Configuration item (CI) will be used from now on. The basic mechanism used to prevent conflicts by simultaneous modifications is that of locking.
The composition model is an extension on the check-out/check-in model. This model allows developers to think in configurations instead of individual files. Although the complete check-out/check-in model is represented in the composition model, it enables the use of different strategies for updating through the use of improved support for the management of configurations. A configuration is defined as being built up from a system model and version selection rules. The system model determines which files are used, while the version selection rules determine which version of the files (e.g. the latest versions or of a certain development state).
The long transactions model takes a broader approach by assuming that a system is built up out of logical changes. Its focus is on the coordination and integration of these changes. Basically, it uses versions of configurations and versions of files. A configuration is created based on a change request which is stored separately. Files in this configuration can be synchronized using the check-out/check-in model. When the change is completed, the complete configuration is stored back into the repository and integrated with other changes.
The change set model also works based on change requests and has a lot in common with the long transactions model. However, it starts with a certain configuration as the basis for changes. This is then changed according to the independent change requests that come in. New configurations of the product are then created by applying sets of the independently stored changes on the baseline version.
This entry covers the check-out/check-in synchronization model, including a meta-model (a process-data diagram). Because the check-out/check-in model is also included as a part of the other models discussed above, it is therefore further elaborated upon. Issues that are not discussed in detail are the three remaining synchronization models and the actual editing of CIs together with the methods related to this.
Concept | Definition |
---|---|
Version | A version is a state of an object or concept that varies from its previous state or condition. |
Configuration item | An element of software or a document placed under version control. A group of CIs can also be defined as a CI (Crnkovic et al., 2003). |
Configuration item history | A concept to facilitate version stamping. Splits version specific attributes from attributes common to all versions (Van de Weerd, 2005) |
Document | Many types of documentation are part of software engineering. Consider documents that describe the software architecture, technical documentation, user manuals, etc. |
Source code file | A source code file contains any series of statements written in some human-readable computer programming language. A computer program's source code is the collection of files that can be converted from human-readable form to an equivalent computer-executable form. |
Repository | A repository is also called a vault. A repository contains only one complete version of a configuration item. Differences between versions are usually stored using a delta algorithm (Crnkovic, Asklund & Persson-Dahlqvist, 2003). |
Versioning organization | Versions of a CI may be organized in a number of different ways. This is the parent for the concepts that describe the organization of versions (Crnkovic et al., 2003). |
Branch | Versions organized as parallel development lines (Crnkovic et al., 2003). |
Revision | Versions organized in a sequence (Crnkovic et al., 2003). |
Development state | Expresses how the development of a piece of software has progressed and how much further development it may require. Each major version of a product usually goes through a stage when new features are added (alpha stage / state), then a stage when it is actively debugged (beta stage / state), and finally a stage when all important bugs have been removed (stable stage / state). |
This section contains an elaboration on the check-out/check-in synchronization model.
The process-data diagram above describes the different concepts that are applicable in the check-out/check-in synchronization model and their relation to the activities that take place. Central to the meta-data model (right side of the figure) is the Configuration Item. This is stored in one or more repositories and can for example be a source code file or a collection of other CIs. The repository can contain multiple branches and revisions of files. These in turn consist of configuration items.
The meta-process model (left side of the figure) describes the process of the check-out and check-in activities. The activities are explained in the table of activities below.
Activity | Sub-activity | Definition |
---|---|---|
Check-Out | Files are not read or changed directly from the repository. Checking out describes these activities. | |
Copy CI | A particular version of a CI is copied from the repository. | |
Lock CI | If write access is required and if the CI is not already locked by someone else, the CI is locked. Otherwise the CI cannot be written back to the repository (read-only access). | |
Modify CI | The person editing the CI makes changes to it. This is out of the scope of the current meta-model regarding version management. | |
Check-In | The CI needs to be placed back into the repository. Checking in describes these activities. | |
Select versioning strategy | The new CI has to be placed back in the repository using a versioning strategy. This describes the selection of the strategy used to place the CI back into the repository. | |
Create branch | The CI is selected to be the start of a new branch. | |
Create revision | The CI is selected to be a revision of another CI. | |
Select development state | The CI is determined to be of a certain development state. | |
Write CI | The CI is stored in the repository. | |
Unlock CI | The CI is unlocked. |
Feiler (1991) evaluated the check-out/check-in synchronization model. It has the clear advantage that it’s easy to use and understand. However, this simplicity results in a lack of management of configurations, such as product version tracking and checking version history across multiple logically connected files.
The turn-taking mechanism of locking is a real problem as well when working with many developers, as these files cannot be edited by others once it has been locked.
To illustrate the check-out/check-in synchronization model, this section contains an example of how this process works. The figure below contains a state transition diagram of a CI.
When a CI is first created, it is modified and stored in the repository. When someone requests to open the CI, it is first copied to the local machine of the developer (note: there are systems where editing occurs directly in the repository. The copy step however is the classic check-out/check-in way). When that developer also wants to edit the CI, it requests a lock. This can be done directly at the request of opening a CI, but also after some time of reading it. When the CI is not locked yet, a lock is applied and it can be modified by the developer. After modifications have been done, it is stored back in the repository and unlocked. Now, assume that the developer that was just discussed is in the process of editing a CI that is already in the repository. You want to open a CI from the repository and so it is copied to your local drive. You start reading it and find some things you wish to change, so you request to edit it. However, the CI is already locked and you will have to wait for it to be unlocked or close the file and proceed to another one.
Concurrent Versions System is a revision control system originally developed by Dick Grune in July 1986.
In software engineering, version control is a class of systems responsible for managing changes to computer programs, documents, large web sites, or other collections of information. Version control is a component of software configuration management.
Revision Control System(RCS) is an early implementation of a version control system (VCS). It is a set of UNIX commands that allow multiple users to develop and maintain program code or documents. With RCS, users can make their own revisions of a document, commit changes, and merge them. RCS was originally developed for programs but is also useful for text documents or configuration files that are frequently revised.
Apache Subversion is a software versioning and revision control system distributed as open source under the Apache License. Software developers use Subversion to maintain current and historical versions of files such as source code, web pages, and documentation. Its goal is to be a mostly compatible successor to the widely used Concurrent Versions System (CVS).
Code Co-op is the peer-to-peer revision control system made by Reliable Software.
Rational ClearCase is a family of computer software tools that supports software configuration management (SCM) of source code and other software development assets. It also supports design-data management of electronic design artifacts, thus enabling hardware and software co-development. ClearCase includes revision control and forms the basis for configuration management at large and medium-sized businesses, accommodating projects with hundreds or thousands of developers. It is developed by IBM.
StarTeam is a version control system used in software development, especially when a project involves multiple teams in different locations. StarTeam is an SCM and SDLC software application, created by Starbase Corporation, which was acquired by Borland in January 2003 which was acquired by Micro Focus in July 2009. The application is client-server, backed by a relational database that retains all changes made to a project during its evolution as well as the project requirements, task assignments, threaded discussions and bug tracking. Microsoft SQL Server and Oracle database are supported database servers.
Git is a distributed version control system: tracking changes in any set of files, usually used for coordinating work among programmers collaboratively developing source code during software development. Its goals include speed, data integrity, and support for distributed, non-linear workflows.
In software development, distributed version control is a form of version control in which the complete codebase, including its full history, is mirrored on every developer's computer. Compared to centralized version control, this enables automatic management branching and merging, speeds up most operations, improves the ability to work offline, and does not rely on a single location for backups. Git, the world's most popular version control system, is a distributed version control system.
Open-source software development (OSSD) is the process by which open-source software, or similar software whose source code is publicly available, is developed by an open-source software project. These are software products available with its source code under an open-source license to study, change, and improve its design. Examples of some popular open-source software products are Mozilla Firefox, Google Chromium, Android, LibreOffice and the VLC media player.
Microsoft Visual SourceSafe (VSS) is a discontinued source control program oriented towards small software development projects. Like most source control systems, SourceSafe creates a virtual library of computer files. While most commonly used for source code, SourceSafe can handle any type of file in its database, but older versions were shown to be unstable when used to store large amounts of non-textual data, such as images and compiled executables.
Unicom System Architect is an enterprise architecture tool that is used by the business and technology departments of corporations and government agencies to model their business operations and the systems, applications, and databases that support them. System Architect is used to build architectures using various frameworks including TOGAF, ArchiMate, DoDAF, MODAF, NAF and standard method notations such as sysML, UML, BPMN, and relational data modeling. System Architect is developed by UNICOM Systems, a division of UNICOM Global, a United States-based company.
Customer Configuration Updating (CCU) is a software development method for structuring the process of providing customers with new versions of products and updates production. This method is developed by researchers of the Utrecht University.
In software development, version control is a class of systems responsible for managing changes to computer programs or other collections of information such that revisions have a logical and consistent organization. The following tables include general and technical information on notable version control and software configuration management (SCM) software. For SCM software not suitable for source code, see Comparison of open-source configuration management software.
Configuration Management Version Control (CMVC) is a software package that serves as an object repository, and performs software version control, configuration management, and change management functions.
Azure DevOps Server is a Microsoft product that provides version control, reporting, requirements management, project management, automated builds, testing and release management capabilities. It covers the entire application lifecycle, and enables DevOps capabilities. Azure DevOps can be used as a back-end to numerous integrated development environments (IDEs) but is tailored for Microsoft Visual Studio and Eclipse on all platforms.
A Definitive Media Library is a secure Information Technology repository in which an organisation's definitive, authorised versions of software media are stored and protected. Before an organisation releases any new or changed application software into its operational environment, any such software should be fully tested and quality assured. The Definitive Media Library provides the storage area for software objects ready for deployment and should only contain master copies of controlled software media configuration items (CIs) that have passed appropriate quality assurance checks, typically including both procured and bespoke application and gold build source code and executables. In the context of the ITIL best practice framework, the term Definitive Media Library supersedes the term definitive software library referred to prior to version ITIL v3.
PTC IntegrityLifecycle Manager is a software system lifecycle management (SSLM) and application lifecycle management (ALM) platform developed by MKS Inc. and was first released in 2001. The software is client/server, with both desktop (java/swing) and web client interfaces. It provides software development organizations with a collaborative environment in which they can manage the end-to-end processes of development, from requirements management, engineering change management, revision control, and build management to test management and software deployment as well as associated reports & metrics.
Plastic SCM is a cross-platform commercial distributed version control tool developed by Códice Software Inc. It is available for Microsoft Windows, Mac OS X, Linux, and other operating systems. It includes a command-line tool, native GUIs, diff and merge tool and integration with a number of IDEs. It is a full version control stack not based on Git.