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

Version Control of Model Data

Using version control in Enterprise Architect consists of placing individual model packages under version control, rather than version controlling the project as a whole.

Guide:

Topic

Detail

See also

Version Controlling your Project files

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

In simple terms, the project file 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.

Therefore, avoid placing your .EAP files under version control, as this can create 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)

 

Version Control Basics

Version Controlling Packages in your model

To overcome the limitations described above, Enterprise Architect exports discrete 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.

 

 

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.