Versioning and MetaEdit+

When moving from coding to modeling, the need for version control decreases significantly. Essentially it goes back to what it was initially, which is the need for backups and to be able to return to a certain state of the product, e.g. corresponding to what was shipped in a particular release. The other features of version control systems such as merging and branching are handled by things like the multi-user version, proper separation of concerns (weaved back together by the generator), and product line analysis of commonality and variability. 

DSM's strong emphasis on reuse and integration between models, something which plays an important role in the productivity, quality and ease of use benefits of DSM, means that many common problems of version control with code files are no longer encountered. E.g. if you change the name of an element (function) that is used (called) by several other elements (functions), there is no need to update those places where it is used. Since that one element will be shared between several graphs, it no longer makes sense to think about a graph as an atomic unit, which could be versioned separately from other graphs. If an object A was used by several graphs, and each graph could be moved back and forth independently in its version history, you would end up with the impossible need for several different versions of A to be in force at the same time.

Instead, the versionable unit is a repository. You can choose to make the repositories as large or as small as you want, depending on your versioning needs - e.g. for a single feature, a single product, a related set of products, all this year's projects, all projects ever etc. The bigger you make them, the more you can have reuse by proper direct reference to other elements, but the larger the unit of granularity that you can return to in one step (i.e. everything in the repository goes back to the previous version, and if you want some parts you need to export, import and fix up links). The smaller you make them, the less you have true reuse and the more you have to make references by typing the same string in several places, but the easier it is to revert one part of the whole to an earlier version without affecting everything else or having to import, export  and fix up links.

Best Practices

We do not recommend using the various export options to get single files for version control of models. There will normally be significant amounts of data that are reused in several models, or references between models, so trying to export individual graphs will lead to problems of overlap between the files. Instead, we recommend splitting the work based on standard modularization principles of high cohesion inside a module, low coupling between modules, and each module being edited by only one person.

Firstly, we would recommend that you keep a separate repository for working on the metamodels and generators. That repository will only be accessed by the metamodeler(s), and after logout following each good set of changes, it will be zipped and the resulting file saved in your normal version control system*. From that repository you can also save the metamodel, including the generators, as a .met type patch. In the multi-user version, that file can simply be imported to the main repository and all users models will update automatically. If modelers each have their own single user repositories, you can inform them so they can update to the new version of the metamodel.

For the models, we would recommend that the work is divided so each repository is for one clearly bounded module, which will be edited by only one modeler. Other modelers may want to look at it, but not make changes to it. Each modeler may have one or possibly several such repositories that they are responsible for. After logging out of a repository following a good set of changes, the modeler zips the repository and checks the resulting file into your normal version control system*.

If a single module is too large for one developer, and cannot reasonably be split into smaller units, that repository can be used by a team of developers with the multi-user version of MetaEdit+. When the team leader is happy with a set of changes, he can have the modelers log out, suspend the MetaEdit+ database server for that repository, zip it and check it in to version control*.

Since a MetaEdit+ repository consists of many files, which must be treated together as one conceptual whole, the repository directories should not be kept under automatic version control at the file system level. Most version control systems only really understand a single file as a versionable unit, so the repository must be zipped into one file, and that file placed under version control*.

These practices have been found to work well in organizations that are used to using standard current practices of version control: many developers, many code files. They scale well to hundreds of developers over dozens of sites, spread across several continents, and with development continuing for over a decade.


* MetaEdit+ 5.5 automates the integration with Version Control Systems, allowing the user to remain logged in. The automation also removes the need to zip the repository; experience shows that in most cases the VCS will remain more compact without zipping. Using the automated integration ensures that all files of the repository are maintained at the same version.