Git support

[Eve]

I need git support and I can handle "lack of locks".

Then just use controlled packages and manually commit to git. The main thing that the version control integration in EA offers is UI integration with the locks provided by version control.

[qwerty]

With a large grain of salt: do NOT use git's merge. Except you like cleaning up your shattered model afterwards.

q.

[Paolo F Cantoni]

With a large grain of salt: do NOT use git's merge. Except you like cleaning up your shattered model afterwards.

q.

As I have said many times. Version control of these types of models is a "chimera".

Models are NOT source code.

As was said (I think) on "The Sopranos", "forgeddaboudit".

Taking snapshots by means of the "Transfer project" functionality has worked for us for over two years at an enterprise scale.

Paolo

[RoyC]

>> As was said (I think) on "The Sopranos", "forgeddaboudit".

No, it was '<something> Blue Eyes' with Hugh Grant, but I'll go with the intent.

[Eve]

As I have said many times. Version control of these types of models is a "chimera".

Models are NOT source code.

That's true, but I think you'll find that the differences aren't all that great. Mainly the difficulty merging a model comes down to the syntax that is used to represent it in a text form. If a syntax similar to source code was used to serialize a model, existing merge tools would likely find it much easier to work with. Just by using stable ids instead of names to reference things, you would actually solve a lot of problems caused by existing merge. (And if the tools around it were able to display the name instead, you wouldn't be losing human readability)

I'd go so far as to say that code is actually a definition of a model. Although I won't say that existing code models provide easy or one to one mappings between visual models.

[Paolo F Cantoni]

As I have said many times. Version control of these types of models is a "chimera".

Models are NOT source code.

That's true, but I think you'll find that the differences aren't all that great. Mainly the difficulty merging a model comes down to the syntax that is used to represent it in a text form. If a syntax similar to source code was used to serialize a model, existing merge tools would likely find it much easier to work with. Just by using stable ids instead of names to reference things, you would actually solve a lot of problems caused by existing merge. (And if the tools around it were able to display the name instead, you wouldn't be losing human readability)

I'd go so far as to say that code is actually a definition of a model. Although I won't say that existing code models provide easy or one to one mappings between visual models.

Yes, they aren't that far apart, but it's the differences that are crucial here, in my view.  If you have a single project model in a simple repository you can use version control, because changes are local and pretty coherent.  Indeed since (as you (and I) say) code is the rendering of a model, it's the nature of source code that allows you to use version control.

For enterprise-wide, multi-profile repositories, ALL BETS ARE OFF...

Paolo