Hi,
the technical stuff and the scenarios haven't changed a lot since 2010. All the information are still valid. Go to Resources on the Sparx Site (e.g.
http://sparxsystems.com/WhitePapers/Version_Control.pdf).
DBMS:
Just a more reliable solution as *.eap files. With a DBMS you can work with a large team on one repository without bothering about corrupted *.eap files and more. It's the solution if you want to work on valuable and reliable information. Have a look on ERP systems with Access or Accounting with Excel, It works in principle but...
Version Control, e.g. with SVN:
A typical Use Case is: You want a historical release of a package of your repository / model. Think of it and of the dependencies to other packages.
Some processes like SPICE, Functional safety, CMMI requires Version Control. Then it's difficult not to use it. It's similar to code development with SVN. In practice Diff/Merge isn't an easy task. To summarize: Think carefully about using Version Control. It isn't easy to profit from the theoretical advantages (there are a lot of discussions in this forum, search for Version Control, SVN, Merge)
DBMS:
In my opinion a must have if you work in a team and your data are valuable for you. It's easy to setup and maintain.
SVN / Version Control:
+ Version Control ( if your process requires it)
+ Parallel Development, in theory, mostly it won't work in practice (a lot of information in this forum)
+ In a distributed environment (very slow WAN) it is sometimes faster in combination with a local repository
- Diff/Merge don't give the results you may expect (try it for complex changes and dependencies between packages)
- Some unexpected errors with EA ( I invested a lot of time searching for them, possible lost of data)
- Setup needs some time
- Checkin / Checkout needs extra time
There are a lot of possible solutions to do it with Version Control:
- Central Repository (Everyone looks at the same data)
- Local Repository (Everybody has it's own local repository and synchronization is made by Version Control and Checkin/Checkout)
Just think:
You have the same information in a database and in a Version Control system as *.xml files. If you need a historical release of a package you can check out this historical release of that package. You can compare it and merge it. You may have more than one repository to handle it. It works but it comes for a price. The problems are the dependencies to other packages under Version Control.
If you really want Version Control give it a try and test it with realistic changes according to your Use Cases. Don't think of a repository as a flat text file with code. Dependencies, seeing and handling them are the challenge.
Regards,
Helmut
