Version Control of Model Data
When applying version control in Enterprise Architect, you place individual model Packages under version control, and not the project as a whole.
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. Being binary data, the project file 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, it is not practical to apply version control to the database (.eap file) as a whole; this can also 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; the system displays an error message and fails to load the model if it is read-only
Version Controlling Packages in your Model
To overcome these limitations, Enterprise Architect exports discrete units of the model - the Packages - as XMI Package files, and it is these XMI files, not the project 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, many users can work on separate parts of the model simultaneously.
Version Controlled Nested Packages
Version controlled nested Packages result in much smaller XMI files being exported, 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 of small individual Packages, provides greater scope for multiple users to work concurrently, as individual users are locking much smaller parts of the model.