!!PLEASE HELP!! BAD problem with replicas

[Geert Bellekens]

That seems very weird indeed.
I have the idea that the whole replication thing is kind of screwed up.

If the xmi compare does not show differences I guess you can safely assume that both are are in fact equal.

Geert

PS. I do sleep from time to time, but I have small children that sometimes wake me up in the middle of the night, and while waiting for them to go asleep I sometimes get bored and check my email

[ebeb]

Hi!

I just wanted to ask, if there is any progress with this issue or consensus what and how to do to prevent this mess. I'm asking because I want to use replicas in a similar use case as described except that we actually are geographically dispersed and have a high latency WAN and am kind of afraid now .

If he works for you, give him a raise.  If he doesn't, hire him.

[smiley=thumbsup.gif] [smiley=thumbsup.gif] [smiley=thumbsup.gif]

[Geert Bellekens]

what and how to do to prevent this mess.

Don't use it

Geert

[EricP]

I just wanted to ask, if there is any progress with this issue or consensus what and how to do to prevent this mess. I'm asking because I want to use replicas in a similar use case as described except that we actually are geographically dispersed and have a high latency WAN and am kind of afraid now .

Good morning, ebeb.

The consensus, if there is one, seems to be to use XMI compares to resolve conflicts.  I found that that kinda, sorta worked, but not really, then I ran out of time to work with it (or to document it in a way that I could intelligently discuss the shortcomings).  Basically, I had to pick an interim solution, and get back to work on the project.

I found that after merging the replica back into the master, all of the conflicts were in the replica, and none were in the master.  So, the other software engineer and I checked the master to verify that at least the easily-visible stuff was as it should be (attributes and methods of classes, links between classes), then we discarded the replicas and generated new ones.  We have been working with those since then and so far, so good.

We have resigned ourselves to the fact that we can no longer trust the EA database as the final authority on the system.  Our ideal solution would have been to make all changes in the model and then generate new code and it would Just Work.  That's no longer possible (if in fact it ever was), and so we're considering the code as the final authority, making all necessary changes in the code, and then re-sync'ing the code back into the model.  Come design review time, we'll have to manually inspect all aspects of the model to make sure it represents the real world (code) rather than inspecting the code to make sure it accurately represents the model.  Kind of a backwards way of doing it, and not what I wanted, but it's working that way and it's not a huge amount of extra work.

What I would really, Really, REALLY like, in EA 7.6, would be that in the event of conflicts after merge, I call up the conflicted diagram and I see the master version of the conflict in one color and the replica version of the conflict in another color.  Then I could just select and delete the things that are incorrect and keep the things that are correct, then save the diagram and the problem is solved.

Maybe the Sparxians will do something like that...

[ebeb]

Hey Eric,

thanks for the reply.

I actually don't get it why you were initially using replicas. You wrote in one post that you wanted to access different packages of one eap file from different users.

That works very well with one single shared eap file, even better with additional version control set up.

In our case, we have one eap, and most of the packages VCed using SVN. That assures that only one user is accessing a package at a time.

The only reason for us to use replicas is the high WAN latency when accessing the eap file when doing home office.

[EricP]

I actually don't get it why you were initially using replicas. You wrote in one post that you wanted to access different packages of one eap file from different users.

We aren't using "packages" in the sense of UML "packages", though I've found that some of the EA features that work on "packages" also work on individual diagrams that EA considers "packages", like XMI export.

Instead, what I did was implement what someone else here characterized as the "kitchen sink" diagram, that contains everything in the model, then sub-diagrams are implemented where each element (class, struct, etc.) is a link to the corresponding element on the kitchen sink diagram.  That works well, except that any change that's made to a sub-diagram also shows up on the kitchen sink diagram, so all those changes have to be merged in from different users.  I don't know of a way to do that other than with replicas.

Perhaps that wasn't the right way to do it but I ran into problems with UML packages on another project, mainly regarding how to maintain connections between packages and account for the fact that certain classes, structs, and enum lists are used in many (most) packages.  I haunted this forum and Sparx support for a while trying to figure that out and never did come up with a good solution, so for this project I decided to use replicas, trusting that they would work better than they apparently do.

If we had a better way to resolve conflicts, like what I suggested earlier about showing conflicts in different colors on the diagram, replicas would work just fine.