I'm not sure if replicas are the 'only' way to split for large projects, but we used them on a 20-user project and they are a bit hairy.
Replicas don't actually split a project, they replicate the whole master model (database) file into a replica model (database) file; users can seperately edit their own copy of the replica, then send it back to a central administrator for merging into the master. Anything deleted/modified/added in the replica is deleted/modified/added in the master when the replica is merged in. We used replicas because the a) the company does not have IT infrastructure/willpower to have a server for its global users(!) and b) many users needed to do offline editing, e.g. while travelling.
EA replicas are based entirely on Microsoft Access database replication, so the basic technology works, but EA could provide a better layer of model management on top of it.
Some of the difficulties we had (on EA 3.60) :
1. If you don't use locks, anyone can change anything in any replica, and their changes, wanted or not, get merged back into the master. You have to keep an eagle eye out for 'helpful' users who thought the replica file was too large so they deleted everyone else's packages and compacted the file to make it smaller so they could send it by email!
2. If you use locks, the locks only work for a single named user; you can't allow more than one username to access one part of a model. We ended up letting several people use the same username when we used locks.
2a. If you use locks extensively, when the administrator needs to make model changes as he manages merging, he has to undo and redo locks on any packages he needs to tweak. This is a *real* pain.
3. As successive replicas get merged, EA (Access actually) decides what happens if the same element got changed two different ways in two different replicas. It does claim to give you a list of 'conflicts' which might help you spot where this happens, but I was never convinced about this enough to trust it. We had to try to manually enforce single-user editing of each package, which wasn;t always successful!
4. One replica got corrupted when the users' laptop crashed while he was using EA. He didn't realise it was corrupt, and it got merged into the master. The master had the same corruption for a while until we realised. Managed to recover by exporting the affected package to XMI, deleting it and re-importing, but I felt very lucky when this worked. EA does have model consistency checking, but it doesn't give much more than 'element 101232342 corrupt' level of error message, and won't let you fix individual problems it finds. I raised this to support at the time, don't know if it has been improved.
We ended up with a tightly run process for managing replicas, which involved keeping a copy of every master model and of every replica which we merged into it, so that at any point we could roll-back if needed.
My own conclusion is that EA is very good for the price, but it is really a single user product which is being stre-e-e-e-etched to fit a largely multi-user market. Replicas should be used with extreme care, and you may well still have problems! EA+Replicas is a poor substitute for a proper multi-user repository UML environment with proper access control. You may save money on the tools only to spend more on administration, management, hassle and hair-replacement.
What is the value of your model after 20 users have spent 6 months working on it? 20 users @ $50/hour (=$400/day=$2000/week=$8000/month=$48k/6months)= $1m! Now, spending $100k on tools looks cheap; think of it as insurance. It would mean that it is much less likely that one laptop crash or a dozy user could corrupt your $1m investment.
Sorry, this seems to have turned into rant. Its just that replicas made me very nervous. We did get them to work for us, but it felt very seat-of-the-pants stuff.
Oh, and we never even thought about doing version control, that looks like another 'interesting' area of EA's feature-set. Doesn't look very scalable to me.
HTH
Barny
