Baselines or version control

[GrahamL]

Hi
I head up a software team of 5 members who work i the same office or from home.

We have our models stored in an RDMS and I want to consider the best way of implementing version control.
I think there are two options  -

• Use a version control application (in our case that would be Perforce)
• Use Baselines an user locks

I would like to ask what other users have used and hope to form an opinion as what is most appropriate in my case

Thanks

[Geert Bellekens]

Graham,

You mention wanting to implement version control (solution) but you haven't mentioned why (requirement)
What problem do you hope to solve with version control?

Geert

[Uffe]

Hi Graham,


Those are the two main options, yes. And as always with this kind of issue the answer is "it depends."
One of the things it depends on is who you ask. I favour baselines myself.

External version control systems are built to manage source code, where fundamentally each file is complete on its own. This isn't the case with XMI-exported UML models (which is what EA stores in a VC repository): model A may be dependent on model B to the point where A is incomplete without B. If you like, you can think of the EA GUI as showing a compiled view, rather than a source view.

EA's baseline functionality includes management of references. It's not perfect, but it's something.
The VC functionality on the other hand, doesn't handle references (last time I looked).

Baselines are the better choice when working in a single shared project, VC is more indicated if team members are working in individual projects (however, the addition of RAS baselines in 15.1 makes the individual project / baseline combination more viable). This view is somewhat controversial, and if Geert gets on here he'll tell you different.

The big disadvantage with baselines is that they provide no backup-type functionality. They are stored in the database and if you delete a package, you also delete all baselines taken of that package.

To this I say 1) no version control system is a backup system, if you're using it for that even slightly you're doing it wrong and it will all end in tears; and 2) I strongly suggest setting up a RAS project where you store your baselines. That way they are out of your working project.

Another really big disadvantage of baselines is that they provide no visual indication in the browser, as VC packages do. There is no workaround for this.

Finally, there is a third-party solution from LieberLieber in Germany (no affiliation) called LemonTree I think. I have no experience with that, but it was designed to address this problem.

HTH,


/Uffe

[Eve]

External version control systems are built to manage source code, where fundamentally each file is complete on its own.

Source code references things in other files all the time. I don't think that's the problem.

The auto merge capabilities that they use are more suited to source code. EA version controls at the Package level, which means you're more likely to need merging. Personally I'd also say that XMI is less human readable.

The end result is many more conflicts or bad merges when version controlling an EA package.

[Uffe]

External version control systems are built to manage source code, where fundamentally each file is complete on its own.

Source code references things in other files all the time. I don't think that's the problem.

Well not to hijack the thread here, but it's part of it.

A source file is text. You can view it in its entirety independently of any referenced source files. It won't compile without those references being resolved, but you can look at it, and edit it, without having access to the references.

An XMI export contains a package hierarchy, including elements, diagrams and sub-packages. But a diagram may contain elements which are located in a different package hierarchy. If that package hierarchy is not available when you import the package, those elements will be missing from the diagram.

This is what I mean when I say that an XMI-exported model (= package hierarchy) can be incomplete and that the GUI displays more of a compiled view than a source view, and this issue (in my view) is at the heart of the version management problem.

If you use RAS there is (some) handling of references, so that if you import a package A which is dependent on another package B (and package B is also in RAS), you can choose to import A and its dependencies. You don't get that with the external version control functionality -- do you?


/U