Replication

[simonoff]

I have a small 2 person project in which we thought we were going to be able to use EA. We just can't figure out how to have 2 people contributing to the same model.

We looked at simply sharing a single model file, the network response time is not such that this will work. One of us is remote, accessing the network through the WAN, and response time is just horrible.

So we played with replication for awhile. We could find no rhyme or reason with how conflicts were resolved and reported. If we changed the data type of a property of a Java bean, sometime it would be reported as a conflict, sometimes not. It also seemed that sometimes the conflict was reported in the master project and sometimes it was reported in the EA instance of the replica, if it was reported at all. Changing other attributes simultaneously was also pretty random as to what happened.

We have been trying to figure out how to segment, by package as recommended, our work. But I am stumped. If we divide the sequence diagrams up, we will still be accessing the same underlying classes. I just don't see how to divide things up so we don't have the possibility of hitting the same object.

Am I missing something, it doesn't seem like sharing via replication works. We read all the docs on the subject, maybe we are doing something wrong. Here is the process we followed:

1) Create a few classes and attributes - then make this project a master
2) Make 2 replicas (rep1 and rep2)
3) In rep1 change foo.bar from a String to an int
4) In rep2 change foo.bar from a String to an Object
5) Open the master project
6) synchronize rep1
7) Look in master's replica resolution report (none reported). Verify that the data type has changed - it has.
8) Look in rep1's replica resolution report (none reported). Look at the data type, it is still OK.
9) Open master again
10) synchronize rep2
11) Look in the master's replica conflict resolution screen. NONE reported!!! Check the datatype - it is now Object!
12) Open rep2 (and close master)
13) See what that data type is Object. Look at the rep2's conflict resolution report - it shows a conflict on Modified Date only. there is no place I can find that shows that there was a conflict on the attribute's data type. I also can't figure out what a conflict on Modified date is.

In essence, there is not any indication that we both changed the same thing at the same time. We have tried this same thin on other attributes with varying results. Sometime we get notifications and other times we don't. We are very concerned that the apparent non-deterministic behavior will mean we will never have the least bit of confidence in our model. So ANY help would be greatly appreciated.

This tool looks pretty nice and I would hate to have to back off of using it because 2 people can't work on the same model.

THANKS!!!

[Martin Terreni]

very good you published it here.
hope an answer will be published.

[thomaskilian]

(pre: I may be totally wrong with what I say below. It's just my observation)

I was also stunned when I first came across this. The "conflict" is not that easy to solve. EA just takes the last change and kicks out the previous ones. You can use the conflict table to get back to a previous change - nothing else. Having understood this I simply divided responsobilities between people working on a project disallowing simultaneos changes. Probably the wording could be a bit clearer. Instead of conflict EA should talk about history.

[Martin Terreni]

I trivial definition for conflict would be very simple:

               if more then one diferent change on same object was done by diferent users on same source version then tou have a conflict.

               if EA does keep history it should be no problem to automise this check you're advicing to do manualy.

[thomaskilian]

Probably it could be done, but obviously it isn't. Sparx should comment on this...

[mikewhit]

From EA Help file:

Note that if two or more people work on the same element (package, diagram, etc.) then the replication engine has problems in resolving which change is the master. To avoid this, always work on separate areas in the model when you are using replicas.

Not very helpful, sorry !

Obviously this is always a limitation when using replicas - deciding which change has priority, especially if there are complicated inter-relations.

[Martin Terreni]

no need for EA to deside, it just has to diplay the conflict.

[simonoff]

I don't want EA to decide on ANY conflicts. I want them reported, since there is little change, that in a true conflict, EA will decide correctly.

First, it is obvious that once a project is created as a master, then each replica created causes a significant increase in size of the project. One might presume that this means that the reference data (and more?) is being stored in the master. Possibly, the replica file AND the new content of the master is actually the model data completely duplicated! If this is the case, the infrastructure is there to do this correctly.

Consider the master file being made up of [master_data, rep1_data, rep2_data]. Then replica1.eap contains rep1_data and replica2.eap contains rep2_data.

When replica1 is synchronized, EAP needs to compare ALL data in master.rep1_data with rep1.eap.  If they are the same, merge replica1.eap into rep1_data AND master_data. Now, when replica2 merges, replica2.eap is compared, in detail with master.rep2_data. If there are differences, then for each difference compare master.rep2_data with replica2.eap => If there is no change in these elements, then there are not conflicts merge away. If there are any conflicts prevent the merge, display the report and await resolution.

Can someone from EA comment?