DBMS Repository with many projects

[pzu]

Hi,

I've started using DBMS repository and I put some projects into it. Right now I have some questions about the way of work with it.
I've got Security & Require User Lock To Edit enabled.

I'd like to implement such work scenario with Sparx EA and DBMS repository:
1. There is a version 1.0 of package foo.
2. UserA makes "branch" of package foo.
3. UserA makes some changes in foo branch within few days.
4. While UserA makes changes in branch, everyone see and can use version 1.0 of foo. It's not explicit for other users that UserA is doing something in a branch.
5. When UserA is done with changes he asks his leader for approval.
6. Leader looks at UserA's changes in the foo branch and reviews it (I mean remotely via Sparx EA of course)
7. Leader approves changes.
8. UserA commits his changes to the 'mainline' as a version 1.1 of package foo.
9. From that moment version 1.1 of package foo is seen as a current version for every user.


(by Branch i don't mean folder / package like in Sparx EA documentation)
I mean branch like in SVN or CVS. By mainline I mean a place where all approved / tested versions of models are - it's not for changes. Branches are for that. Mainline if default space - I see it when I log into repository.

So what do you think? Is there a way to implement such scenario with EA and DBMS repository?

[Helmut Ortmann]

Hi,

not an easy and risk free task.

To my opinion you need for one branch:
- 2 DBMS Repositories (main + branch)
- Two sandboxes (MKS term for local path)
- Two Unique IDs to point to your two local paths
- A lot of discipline (e.g. cross references, ..)
- Good testing

With MKS it should work, with SVN I have only little experiences.

Good luck,

Helmut

[Geert Bellekens]

I can be done, and is quite easy as long as you allow exclusive locks.

This means that your point 4

4. While UserA makes changes in branch, everyone see and can use version 1.0 of foo. It's not explicit for other users that UserA is doing something in a branch.

is not 100% true anymore. Users can still see and use version 1.0, but they cannot change anything to it anymore.

I would use two databases, lets call them trunk and branch.
You then make sure to version control all packages in your trunk model.
Then you make a copy of your trunk db into your branch db.
From your branch you can then check-out the packages you need.
After the review these packages can then be checked in into the version control system, and you can do a "getlatest" on those packages from your trunk db.
Then you can make another copy of the trunk to the branch db, just to make sure you start clean again.

I will indeed require some discipline to keep branch and the trunk db in synch, and the performance of checkout/checkin for large packages is far from great, but it should be doable.

Geert

[Geert Bellekens]

Forgot to mention, you could do exactly the same thing with .eap files (or a mix of dbms and .eap)

Geert

[pzu]

 Helmut, Geert thanks for your suggestions, I'll definiately consider them