Git support

[mikhaila]

is git supported in EA 10? if not - why and when it will be supported?
[original message]

[Bellekens@localhost Geert Bellekens]

No, and it will probably never happen.

EA can only do version control with exclusive checkouts, and that is exactly what's not possible with a distributed version control system.

Geert
[original message]

[mikhaila]

'Exclusiveness' in Git and in any DVCS can be easily implemented. According to your strange argument I have a feeling that you don't really understand what is Git and what is DVCS in general. Git is much more powerful than SVN, CVS and other old-school monsters.

More and more software developers and companies are switching into Git/Mercurial/etc. if EA will not support DVCS (which is quite simple to implement) then they may loose part of the market.

Looking forward to see Git support implemented.
[original message]

[M@localhost Simon M]

Geert is right. The problem is the lack of locking provided by GIT. EA files in version control have to be considered binary/non mergeable. That's why locks are necessary. Any locking requires a single source of truth, which just doesn't work for a distributed version control system.
[original message]

[mikhaila]

3923272524274A0 wrote:

Geert is right. The problem is the lack of locking provided by GIT. EA files in version control have to be considered binary/non mergeable. That's why locks are necessary. Any locking requires a single source of truth, which just doesn't work for a distributed version control system.

I don't see any problem here. Git merges binary files better then SVN.
Also Git will store changes in binaries as delta-copies. And I still don't understand clearly why do you need a lock?
[original message]

[Bellekens@localhost Geert Bellekens]

Ok, let met try to explain.

When EA does version control on a package it exports the package to an xmi file, and stores that xmi file in the version control system.

When you do a checkout, the latest version of the xmi file is imported into EA.
When you do a checkin, an EA creates a new xmi export of the contents of the EA package.

Now what would happens if two users would, independently of each other create a new version of a package?
In an ideal situation GIT would be able to merge the both xmi files into one large xmi file that would then be stored in the repository.
Then each user would be able to get a latest version of the xmi file, and import that into his model.

Few concerns:
- is a merge of two xmi files still a valid xmi file?
- what with conflicting changes? The users would then need to resolve these conflicts in xmi format, which is unreadable for humans for all practical purposes.

I'm afraid the above scenario would corrupt your model quicker than you can say "I hate XMI!" :o

Geert
[original message]

[qwerty]

I guess that a search for "git" would have revealed your answer more than once :-/

q.
[original message]

[mikhaila]

67454552540E62454C4C454B454E53200 wrote:

Ok, let met try to explain.

Few concerns: - is a merge of two xmi files still a valid xmi file? - what with conflicting changes? The users would then need to resolve these conflicts in xmi format, which is unreadable for humans for all practical purposes. I'm afraid the above scenario would corrupt your model quicker than you can say "I hate XMI!" :o Geert

OK, I see your point. I think you are breaking here one of the famous OOD principles from SOLID pattern - Single Responsibility Principle.
I think that you are trying to solve problems you should not solve;

The synchronization issue that you've just mentioned about can easily be solved either technically (e.g. using discretional access control in Git - which is not possible in SVN/CVS) or organizationally by making an agreement.

So, leave the above issues to a user. Let us do our job with all the flexibility available. Just add Git support and EA will be the coolest tool among others!

Thanks!
[original message]

[g.makulik]

434745464F47424F2E0 wrote:

So, leave the above issues to a user. Let us do our job with all the flexibility available. Just add Git support and EA will be the coolest tool among others!

EA does so. You can still setup controlled packages just from XMI files. How you're going to manage these without SVN or another directly supported version control system is up to you. Just keep your XMI exports in a GIT repository and sync your local EA database with these (good luck).

Just my 0.02$
G�nther

[original message]

[RoyC]

Just a reminder that this is a user forum, for users to talk amongst themselves. Sparx employees participate in discussions at their own discretion and on an ad hoc basis, with no obligation or commitment.

Geert is not a Sparx employee. I wish he was - he is an exceptionally knowledgeable, talented and generous person, unlike some other correspondents.

If you want to make comments, reports, requests or complaints directly to Sparx, please send an email to Sparx Support, or a formal bug report or feature request using the links in the Support column at the foot of this page.

If you have language or comprehension difficulties, I have also made a suggestion in the first posting in this General category, that you ask other forum users (or your own colleagues, perhaps) to guide and assist you with translations.
[original message]

[qwerty]

743D7E7278667F7A78130 wrote:

(good luck).

Yep. Let him fall into that pit...


685543793A0 wrote:

unlike some other correspondents.

Like me ...

q.
[original message]

[qwerty]

Just for the fun of it try the following (it took me less than 5 minutes):
- Create a new EAP with a view containing a single class "Class1"
- On the root issue Package Control/Configure and specify a path to a (temp) git repository
- Issue Package Control/Save...
- Commit the created XMI to git
- Clone the git repos
- Open a 2nd EA instance
- From the root issue Import Model from XMI (the clone) and place it on top
- remove the unused root
- Issue Package Control/Configure once again and adjust the path to point to the clone git repos.
(This is usually done via local paths and different users/machines but necessary for the local demo.)
- Change the name of the class to "Class One"
- Save the changes via Package Control/Save.. from the root
- Commit the changed xmi to git
- Go to the first EAP instance
- Change the class name to "Class Two"
- Save and commit
- Now pull the changes from repos1 to the clone
-> You will see three manual conflicts in the (very small) XMI.

Imagine what happens with complex (conflicting) alterations on both sides. If that does not heal you I don't have a medicine.

q.

P.S.: Here's the link where Simon explains the lack of git support: http://www.sparxsystems.com/cgi-bin/yabb/YaBB.cgi?num=1337730997/1#1
I was pretty sure there were more threads (also where Geert replied), but search revealed mainly this one  :-/
[original message]

[TomO]

FWIW, I believe Git has a SCC add-on that will allow EA to connect to it through the usual SCC interface.
[original message]

[Konrad Wieland]

Hi guys,

in the meanwhile LieberLieber has developed a solution called the Model Versioner with which you can Diff & Merge EAP files. It can be integrated in Git, SVN, etc.. So you just check-in eap files and if there is a "real modeling" conflict (not a conflict which arises when checking in binaries), you can solve it on the model level.

EN:
http://www.lieberlieber.com/en/solutions/model-versioner-for-enterprise-architect/

DE:
http://www.lieberlieber.com/loesungen/model-versioner-enterprise-architect/

Br
Konrad