I had to chuckle. Steven Kelly over at MetaCase often gives us a hard time over the fact that DSL Tools is still at V1 whilst his company’s tool has been in the marketplace much longer. However, he’s just written a white paper on versioning, from which I nabbed the following instructions for teams working on models:
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.
Blimey, that doesn’t sound much like an agile process to me!
In our out-of-the box experience, we stick to a rigidly simple file-based system in DSL Tools, with the idea that you use regular SCC systems for day-day version control. We’re not very mature yet at links between those files, but it’s something we’re looking at closely right now. We tend to think that a repository is something you use for publishing major version snapshots of models to as they become part of your company’s knowledge repository.
Given that in any major software project with multiple releases, you’ll have branched versions and hence usually a need to merge those branches later, dealing with models can be tricky. I thought it was sometimes a bit rough in the DSL Tools’ world to merge XML files (albeit nice clean ones that match your domain model), but I don’t much fancy the idea of trying to merge a zipped snapshot of a whole repository.
I think it’s fair to say that this is an area where our corner of the industry has a lot of work still to do.
[edited as I forgot to put any hyperlinks or tags in]