Book a Demo

Author Topic: Model versioning and dependencies/conflicts  (Read 2152 times)

michakraus

  • EA Novice
  • *
  • Posts: 2
  • Karma: +0/-0
  • I love YaBB 1G - SP1!
    • View Profile
Model versioning and dependencies/conflicts
« on: October 14, 2007, 04:29:32 am »
Hi,

we have a huge code base and have split our modules into several small ones that are versioned by subversion using XMI export.
One module provides basic services to the other modules. How can I prevent that a change make to this model breaks the others?
For example, if I delete a component from the central module, wouldn't it simply and silently be missing from the other modules then?

Thanks,

Michael

thomaskilian

  • Guest
Re: Model versioning and dependencies/conflicts
« Reply #1 on: October 14, 2007, 08:42:52 am »
I guess only by being quite careful :-/

peter.zrnko

  • EA User
  • **
  • Posts: 253
  • Karma: +0/-0
    • View Profile
Re: Model versioning and dependencies/conflicts
« Reply #2 on: October 15, 2007, 05:33:25 am »
If you have a version controlled package in project A and import it to project B, it will be the same package. It means if you do some changes in A, check the package in, then check it out in B, it will reflect your last made changes to this package.

If you have more versions of package A. E.g.
- version 12
- version 13 (stable)
- version 14
- version 15
and you want to update package A in project B to version 13, it's not possible using the EA versioning capabilities itself.
You have to make a branch/tag of the SVN folder with your EA xmi files. Make a different working copy of your SVN repository directed to this branch. Update it manually to version 13 (using SVN instructions). Then configure Version control settings for your package in project B with this different Working copy. And finally check out (or get latest) this package by EA in project B.
If you make changes to this package in project B and check them in (by EA), they will go to the branch, not to the trunk of your SVN repository. (Although I think you don't want to make changes to your package in Project B.)
If you will have a next major version of your package in project A and want to have it also in project B, just merge the XMI file in the branch with the desired version from trunk. (SVN uses a diff procedure when merging so instead of simple merging it is better to clear the xmi file in the branch, save, check in and only after that run the merge.)

I'm not a SVN guru, maybe it could be achieved in more simpler way.
I'm not actively using this process, I've tested only parts of it. But I think it should work.
Peter