Configuration management in Mega 2009

[jawed-fdj]

Hi 

My question is related to configuration management in mega ? Configuration management is the traking of the object version .

A common scenario is multiple person woking on the same object or diagram, because they work on two different projects ?

Another scenario is the two architect one working on the existant version and other works on the to be state of the object, th object may be a simple application, a diagram, a POS 

How to deal with these uses cases  in a Mega with rdbms database ?

[jhorber · Accepted solution]

Hello  jawed-fdj

If I understand, your question is 'how can I prototype customizations (metamodel,  diagram types..)'?

A simple approach is this one

1) For small changes, work in transaction

A transaction can help prototype many customizations.

Note: so that changes are considered within the transaction, you will need to trigger the event 'refresh context'

Advantages:

• As long as transaction is not dispatched, changes are not committed.
• You can archive the list of changes at any moment by exporting the transaction logfile (command file with .MGL extension).

However, you may need to dispatch your transaction as:

• You need to check the consistency through metamodel compilation.
• Certain changes are not considered without metamodel compilation.
• There can be too many changes to manage...

2) When working in transaction is not possible, build a specific development environment

You can use several environments if you have several working hypothesis.

Reminders:

• Customization impact mainly the system database. As there is one system database per MEGA environment, changes in customization impact the environment.
• Customization should be considered as development. It is recommended to adopt a development methodology. The deliverable (output) is a command file with a set of changes.
• Such command file can be applied to any environment provided its pre-requisite are fufilled (version, existing metamodel). See below.

A command files is valid for:  

• A given version of the MEGA/HOPEX platform.
  If we consider a command file designed for HOPEX V1R1. It cannot be assumed that this command file can be imported in a previous version (ex: MEGA 2009 SP5). Import in a previous version is not supported. Import in a higher version (ex: HOPEX V1R2) require additional steps (conversion) and testing.
•  A given metamodel
  For example: if a command file adds a MetaAttribute to a specific MetaClass, this MetaClass should exists in the environment where it is imported.

See also

Trigger the event 'refresh context'

http://community.mega.com/t5/custom/page/page-id/mega-kb-solution?sid=501D00000012dKkIAI

Best practises to extend metamodel

http://community.mega.com/t5/custom/page/page-id/mega-kb-solution?sid=50120000000mqNKAAY

[jawed-fdj]

I would bring a clarification about my question with this simple use case :

I have to work on the recast of the architecture of a system of applications (group of application), I have to modify some applications attributes, add some message, modify diagrams, but i want to do that in a branch or a version because iam not sure if it will be validated and I have to discuss this with multiple person, so , I cant commit this on the basic repository, 

So what to do, copy the database ? is there some versionning mecanism on mega ?, can we create a branch ofa bibliotech

Please share your experience !

jawed