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

Apply Version Control To Models

All Enterprise Architect models are stored in databases - even the .EAP file is an MS Jet database.

In simple, version control terms, the model is a single entity of binary data. It is not practical to apply version control to the database as a whole. Being binary data, it would require the use of the lock-modify-unlock model of version control, which would mean that only a single user at a time could work on any given (version controlled) model.

To overcome this limitation, Enterprise Architect exports discreet units of the model - the packages - as XMI package files, and it is these XMI files, not the .EAP file, that are placed under version control. The XMI file format used by Enterprise Architect dictates that they too be treated as binary files (therefore it is not possible to merge the XMI files either); however, by splitting the model into much smaller parts, this approach enables many users to work on separate parts of the model simultaneously.

When a user checks-out a package, Enterprise Architect sends a command to the version control system to check-out the equivalent XMI file. The version control system then puts the latest revision of the file into the user's working copy directory, overwriting any previous revision of the file in that directory. Enterprise Architect then imports the package file into the model, updating the contents of the existing package in the model.

When checking-in, Enterprise Architect exports the package as an XMI file, overwriting the existing local working copy of the file. The new file is then checked-in to the version control system.

Nested Version Controlled Packages

Nested version controlled packages result in much smaller XMI files being exported for parent packages, as the parent packages' XMI files do not contain any content for the version controlled child packages.

Version Control of nested packages together with a model structure having small individual packages also provides greater scope for multiple users to work concurrently, as individual users are locking much smaller parts of the model.


  • Do not place your .EAP files under version control, as this creates problems for you.
  • Most version control systems mark their controlled files as read only, unless they are specifically checked-out to you.
  • The .EAP file is an MS Jet database, and Enterprise Architect must be able to open this file for read/write access when you load your model. (Enterprise Architect displays an error message and fails to load the model if it is read-only.)