In the last week I've been asked a couple of times about versioning of DSM models, so it's about time we put the answers down on paper. Explaining versioning is hard, since it's rather different for DSM models than for code (or even UML models), and versioning is many different things to different people. I'm putting together a web page on Versioning and MetaEdit+ to try to explain it, but that page is still something of a work in progress. In short, most of our users find the best solution is that the versionable unit is a zip or .tar.gz of the repository, which can be versioned as normal with whatever system they like.

We're looking at integration with major version control systems and major IDEs for the next version of MetaEdit+. In some ways this is trying to put new wine into old wine skins, but we want to help people have an easier, more incremental path to DSM. For now, check-in/check-out macros, batch files and generator scripts are all viable and easily-built solutions, although the details will vary depending on the version control system, modeling language, and process used.

If you're willing to forego any links or reuse between graphs, it's also possible to look at handling each graph as one MXM file (MetaEdit+'s model-in-XML format), but we wouldn't recommend that. The initial DSM support in Eclipse and VisualStudio is lacking these inter-graph linking and reuse abilities. That lack is one of the major sources of pain for their users, who are having to cobble together all sorts of hack solutions (at a cost of several man-years). Trying to hack MetaEdit+ down to those tools' level will only lead to you too having to build hacks to bring it back up to the level you need -- and you'll be worse off than with the great native support for reuse and linking that we already have!

Talking to experienced developers and users of those tools such as Markus Voelter, there seems to be a shared conclusion that having products built from many separate files, with links between files based purely on typing the same sequence of characters in several places, is one of the major flaws in current software development. DSM gives us the perfect chance to apply sound O-O principles to our development artefacts: if we want to refer to object Foo (e.g. a function we are calling), we point straight at Foo itself, rather than typing the string "Foo" and building some look-up mechanism (a compiler, linker or generator). Of course there are exceptions, and indirection can be a powerful tool, but since indirect links are always possible anyway, the real question is whether the tools can support direct links.