Git support

[mikhaila]

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

[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

[mikhaila]

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

'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.

[Eve]

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.

[mikhaila]

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?

[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!"

Geert

[qwerty]

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

q.

[mikhaila]

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!"

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!

[g.makulik]

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

[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.

[qwerty]

(good luck).

Yep. Let him fall into that pit...

unlike some other correspondents.

Like me ...

q.

[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  :-/

[TomO]

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

[marcosxsilva]

I understand the lack of “lock” in git could cause serious issues.

I manage SW projects since 1996 and in the beginning of my career, we didn’t have access to versioning tools. We used to lock the files by ourselves using physical tokens. In other words, we did agreements on who would change a specific file in a network repository at specific moment.

In fact, configuration management discipline is very old and always depended on management. Locks (as implemented in clearcase, cvs, svn, others…) are cool, but still depends on people. Consider two architects working in clearcase different branches (different config specs). We would have the same problem as git. How to merge .xmi files? 

In my humble opinion, Sparx should offer support to the git infrastructure and let the users do the configuration management by their own.

I believe configuration management strategy is not concern of EA. This is a sole responsibility of project leader or SCM analyst.

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

[qwerty]

Have a look at LieberLieber's LemonTree. Not affiliated. No idea how good it is, but it's the only git-approach.

q.