DBMS versus SVN Versioning

[kwasposer]

Hello,

i have notice, that you can create a DBMS on a server. Currently I was setting up a SubVersion on this server to version my EA Model.

For Team Coollaboration: What would be preferable?

I have no experience so far.

[Geert Bellekens]

Version Control and Central Database are two different things with different goals.

If you simply want your users to be able to work on the same model, then you should opt for a central database.

In case you want a more finegrained control, and the ability to to rollbacks etc..., you can use version control.

You can also combine both. We often do this, and use version control only for specific packages.

Geert

[Uffe]

I'd also add that storing your .eapx or .feap file in Subversion makes no sense except possibly for distribution maybe? As far as Subversion is concerned it's a binary file that you can't meaningfully compare changes in, and Subversion itself is not a backup system.

If you go the version control route, the intended way of working is that you version-control individual packages, not the whole project file. Each user has their own project and check out/in packages as needed. The packages when stored in SVN are actually XMI (text) files.

A DBMS project is not an alternative to version control, as Geert said. It's just a better way of storing the project than keeping it in a single file. A DBMS is much better at dealing with things like multiple concurrent users than a file system is.

As an alternative to version control, you can use baselines. This provides some of the same functionality as version control, but the baselines are stored in the project -- not in an external VC repository.

So there are options. For collaboration I say DBMS hands down. But version control and protection against accidental loss are different requirements, so you need to weigh them against each other.

HTH,


/Uffe

[timoc]

With a DBMS backend you have the option to do both. You can use your free pro cloud server (from v4.x?) to setup a Reusable Asset Service (RAS) server with your DBMS as its backend. You can setup multiple databases to manage different assets.
https://sparxsystems.com/enterprise_architect_user_guide/15.1/model_repository/reuseable_asset_service.html

The RAS works as a kind of version control, one that you can use in a baseline type process and for diffing against your DBMS live model. Or at least that is my understanding. I'm starting to use it, so maybe other RAS users can comment in more detail.

[Uffe]

The RAS works as a kind of version control, one that you can use in a baseline type process and for diffing against your DBMS live model. Or at least that is my understanding. I'm starting to use it, so maybe other RAS users can comment in more detail.

RAS has been around since long before the v4 Cloud Server, and it does indeed work as a kind of version control. In 15.1/4.1 it's been enhanced so that you can now store baselines themselves -- earlier you stored packages (in RAS format) which isn't quite the same thing, although to the end user it's much of a muchness. I haven't tested it out, but I think the main difference (to the end user) is that you work in the baselines GUI instead of the RAS GUI.

I prefer the RAS solution to XMI-based version control (eg SVN) and it's what I usually recommend for mid-to-large installations. But if you're just starting out with EA it's one more thing you have to set up, which means more grunt work before you get to the fun stuff.

There is also a third-party version control solution called LemonTree. No affiliation and I've never tried it, but the LieberLieber guys tend to know what they're doing.

/U

[kwasposer]

Thank you very much for your opinions! I will have a look into DBMS than :|