Book a Demo

Please note : This help page is not for the latest version of Enterprise Architect. The latest help can be found here.

Prev Next

Version Control Locking Overview

Enterprise Architect implements Version Control of your model by exporting Package data from the project database to XMI Package files, which are placed under Version Control in the source-code control application. The XMI file format cannot be merged in the same way as ordinary text files can be merged, which is why Enterprise Architect must enforce serialized editing of Version Controlled Packages, as discussed here.

The Lock-Modify-Unlock Solution

Many Version Control systems use a lock-modify-unlock model to address the problem of different authors in a shared source overwriting each other's work. In this model, the Version Control repository allows only one person to change a file at a time, and access is managed using locks.

Harry must lock a file before he can begin making changes to it. If Harry has locked a file, Sally cannot also lock it, and therefore cannot make any changes to that file. All she can do is read the file, and wait for Harry to finish his changes and release the lock. After Harry unlocks the file, Sally can take her turn in locking and editing the file.

The Copy-Modify-Merge Solution

Subversion, CVS and a number of other Version Control systems use a copy-modify-merge model as an alternative to locking. In this model, each user's client contacts the project repository and creates a personal working copy - a local reflection of the repository's files and directories. Users then work simultaneously and independently, modifying their private copies. In due course, the private copies are merged together into a new, final version. The Version Control system often assists with the merging, but ultimately a person is responsible for making it happen correctly.

When Locking is Necessary

While the lock-modify-unlock model is generally considered a hindrance to collaboration, there are still times when locking is necessary.

The copy-modify-merge model is based on the assumption that files are contextually merge-able: that is, that the files in the repository are line-based text files (such as program source code). However, for files with binary formats, such as artwork or sound, it is often impossible to merge conflicting changes. In these situations, it really is necessary for users to take strict turns in changing the file. Without serialized access, some users end up wasting time on changes that are ultimately overwritten.

Learn more