First of all it is a good idea to stick to some convention in naming each of the profiles, how to arrange them in EA and where to store them on the file system. The proposed convention is one I adopted over a couple of years. You might use your own, but here I describe how I do it.
Currently I work with just three different profile types:
- the main profile with all the elements,
- the diagrams and
- the toolboxes.
For my MDG, I use a simple EAP repository where I create a single view. The name of the view is what will become the identifer and its alias the user readable name of the profile. Inside that view I create <<profile>> packages for each of the above mentioned types. The packages can have arbitrary names which will be used as namespaces. The only and simple convention is that the diagram and the toolbox package have the strings 'diagram' or 'toolbox' inside so they can be identifed as such. Inside the toolbox profile package single diagrams are placed for each toolbox. Here the name of the diagram is that of the toolbox. The MDG that is going to be created is located via the Filename property of view package.
That's all for what goes into EA. Of course you need to fill the single profiles with some life data. You might read my article MDG Intro to find out how to do that.
The MDG repository is stored somewhere on disk. In the same folder, the final MDG will be placed (which name is placed in the Filename attribute of the above mentioned view package). Further it contains a sub-folder called 'Profile Data' which takes - you guess it - the single profiles. Just one sub-sub-folder named 'Profile Data/Toolboxes' where all the toolbox profiles are placed.
Each <<profile>> must be saved individually from either the package or a diagram via the Save As Profile context menu. The convention is easy: the EA package name is identical to the file name. The toolbox profiles are stored under their name in the Toolbox sub-sub-folder.
If you still would use the MTS creation procedure you would not have such a great advantage now. But here a little perl script comes in which you find attached to this article. Once you have saved your single profiles just call the scipt from the command line (you will need to place the GUID of the MDG view package inside once; see line 9). This will access the running EA session, check the profiles against your repository and create a new MDG. Thereby it will increase the release number automatically. If anything has found to be wrong it will croak. This happens when you saved one of the profiles wrong overwriting another one.
If you are using my Perl framework (Extending EA with Perl) you can use the script as an add-in. Of course you can code it in any other language, but I choose Perl for its mighty string operations.
Of course this procedure will not help if you saved one of the profiles in the the completely wrong place, which can also happen as the Save As Profile dialogue always uses the last recent file location, which is only in rare cases that of your desired profile. But from experience I know that most times you simply overwrite the wrong profile, which makes you simply wonder why your MDG does not work. This little script has definitely saved me many hours.