Merging model to DBMS repository

[johnm9]

I have created the DBMS repository for my project.
I have coporate edition with 5 floating license.

I would like to have different laptops get a copy of the model from the repository. Go offline and do modification to any package they want. After that, plug it back to the coporate network and connect to the repository. Checkin the modified model to the repository. If the modified copies of the 5 different laptops are conflict with each other, it alert conflicts and force resolution of model conflicts before check-in.

This is exactly what the cvs does for program code. Does EA support it for EA models? I have read the "Deployment" whitepaper. No idea how to do it. Is there anyone can help?

[Eve]

No, EA doesn't allow concurrent checkout or merging when doing a check-in.

However, if people take their work they can create a baseline of it before checking out the package and merging their changes back into the model and checking it back in.

However, be aware that there was a recent post on the forum about EA not correctly adding diagram elements back onto a diagram.  I haven't tried to replicate this as yet, but you may run into the same issue.

[johnm9]

Thanks Simon.

So, you've mentioned about "merging their changes back into the model..."

Let's try to work through a very simple example to make it clear.
Suppose there is an empty class diagram in repository. Two user A and B:
(1) A and B checkout the diagram.
(2) A add a class locally, CClass with attribute a without checkin.
(3) B add a class locally, CClass with attribute b without checkin.
(4) A checked in CClass

Q: What should B do to merge his model back so that the final repository carry a CClass with attributes a and b? Its absolutely impractical to ask B to compare with A's model with his "eyes" and then checkout A's committed model and add the attribute b manually to CClass. That's not Enterprise at all.

[Eve]

First, some clarifications.  A and B cannot check out the diagram.  They check out the containing package.

At step 1, did they both do an offline checkout?  This is the only situation EA will allow, but it pays to be sure.  I'm assuming they did below.

User B needs to create a baseline of the package.
Then Undo Check-out, followed by Check-out.
At this point User B has User A's changes.
Now User B can run a baseline compare on the package to merge in changes originally made.
This package can then be checked back in, and if done properly will include both users changes.

[Dermot]

An alternative that you can explore is to use .eap file 'replication'.  This would require that the offline users and the main on-site repository are of .eap file rather than the DBMS. There is discussion on using the different alterntives - such as batch XMI, Version control and replication in the Deployment whitpaper on:
http://www.sparxsystems.com.au/resources/whitepapers/index.html
With version control the granulation goes down to Package level, where as, the granulation on the replication is closer to Element level.

[johnm9]

Thanks Simon M. This solution sounds more reasonable. I'll try it out tmr.

For Dermot, I don't see any exit for the "alternatives" like batch XMI. When we are talking about concurrent working on a single model, what we need is to make sure that the modification of every single user can be merged back into a whole one.

"Batch XMI" overwrite the original model everytime you import it back to the repository. I'm afraid no people will treat this as a "shared model" support to be frank. Can you think of any real world situation where this is useful for a team of modeler?

[Dermot]

Replication does support merging - see:
http://www.sparxsystems.com.au/EAUserGuide/index.html?replication.htm

[johnm9]

Thanks Dermot.

Comparing the replicas to the DBMS approach, does the steps suggested by Simon achieving the same result in finding conflicts and solving conflicts?

Is there anything, regarding the merging of concurrently editing model, different in functionality between the two approach?

[RoyC]

Broadly speaking, both methods identify differences between instances of the same data structure, and if those differences are to the exact same piece of data (e.g. Attribute A has value Yes in one copy and No in the other) you decide which value to keep.

However, as stated in the Resolve Conflicts topic in the Replication section, Replication shows the differences in the MS Access DATABASE TABLES for the two replicas. Baselines show the differences between the current PACKAGE in the MODEL and the Baseline of that package.

As Dermot says, Replication is also only possible with a .EAP file in an Access database, not with a DBMS (which you appear to be using).

Replication shows all the differences between the two instances, including those where the two users have made changes to different pieces of data (Attribute A and Attribute B, for example). I don't think you can filter that comparison. Baselines will let you do that filtering, so that you only list the items of data that have conflicting changes; that is what Simon has outlined.

Basically, Joe and Bob do their edits, Joe takes a Baseline of his, washes Bob's changes over his work, then compares the result with his copy. That shows the conflicts.

With five workers, you'd do that four times, washing the cumulative 'master' of the current model over each person's work in turn and then comparing that with the Baseline of the current person's work.

I hope that helps.

[RoyC]

Ummmm - actually, what I said isn't quite true. The final Baseline vs model comparison that Joe does shows all the differences between his work and the master containing Bob's changes, not just where they have changed the same piece of data.

The Baseline method gives a shorter list of differences than the Replication method, but I don't know how any method could distinguish between conflicting changes and changes to separate items; in both cases, the net result is a difference between the value of a piece of data in the two copies.