0

We are using Rational Software architect to model our designs. And we have our repository in Github to Collaborate among team members. Problem we are facing with Merge/Conflicts. So if one team member does some changes in the model and commits/pushes his changes and other tries to pull this change there are lot of conflicts which happen.

Unfortunately these conflicts are mostly to do with changes in the Meta data in the .emx files which RSA makes by itself. These conflicts are very difficult to resolve and these are not human readable lines.

Has anybody else faced similar problems while using RSA with GitHub

Randy Morris
  • 39,631
  • 8
  • 69
  • 76
user667022
  • 351
  • 3
  • 13
  • git is only really for ***source code***. if you are making film games, radio ads, or something like R.S., simply use svn. this question comes up a thousand times with Unity3D for instance. it's just not practical to use "git" for unity game projects. (unity projects are 100s of gigabytes of video, animations, models etc .. and a few hundred bytes of actual source code text files. git is for source code text files. everyone in the game biz (for example) just uses svn.) – Fattie Jun 26 '16 at 01:46
  • How you integrated RSA(9.1) with GIT ? @user667022 – User Dec 18 '18 at 14:45

2 Answers2

1

Your problem is not really RSA but git. And more precisly your git client.

RSA can do a diff or merge that is human readable, it analyzes the semantic of the content of the different versions. But for that, it needs the content unchanged, not polluted by "diff" lines produced by your git client. It just expect to have the original content of the version. Most of version control system think they are able to make a diff themsleves but with complex content they cannot understand the semantic.

If you take CVS, the eclipse client just give the full version s unchanged and delegate the diff to the "rsa diff tool" and everything works fine here.

Sufian
  • 6,405
  • 16
  • 66
  • 120
Erik Gollot
  • 19
  • 5
0

I am currently looking into solutions for the same issue you describe in your question. However, at my company RSA itself is used to sort out these merge conflicts. So my suggested solutions below will not work in full for you if you use a merge tool or editor that cannot work with canonicalized XML files. We do observe the same problems since we use Gerrit to review the code, and as you have stated in your question, the source code is not human readable and therefore impossible to review or comment on within the Gerrit UI.

The source code embedded in the XML documents with the .efx and .emx filename extensions, has been modified or canonicalized so that characters like linefeed, quotes and other have been replaced with corresponding HTML encoded sequences. Git and Gerrit expects each source code line to be terminated with a linefeed, so the result is almost infinitely long lines comprised of all source code lines in the so-called fragment concatenated, interspersed with some HTML encoding sequences.

Someone at our company has at least added a crude diff filter to git so that when you invoke 'git show', 'git diff' and other commands to view file content, the embedded source code lines are human readable. The filter is just a bunch of global search and replace statements replacing about a dozen or so HTML encoded sequences with corresponding UTF-8 characters.

To address this I believe there are basically two alternatives;

1) Add some sort of a filter to Gerrit that works pretty much like the diff filter for git mentioned above, replacing HTML encoding sequences into corresponding UTF-8 characters.

2) Add smudge and clean filters to git that when checking in the code, the source code lines are converted to UTF-8 inside a HTML comment placed adjacent to the HTML encoded line. In Gerrit it will then be possible to see source code as the author intended it making it possible review and comment as normal. On checkout the smudge filter removes the HTML comment and the source code within it leaving the .efx and .emx looking exactly like when RSA wrote the contents to disk. Although this will change the file contents and effectively double the size since the source code is repeated, the contents will remain a valid XML document that should not affect RSA even if the HTML comment should survive the smudge process.

Recently I heard that the latest version of RSA, 9.1 I believe, can be configured to leave the embedded source code in the fragment files more or less intact so that it can be reviewed and inspected in Gerrit without the need for workarounds such as those listed above. I have yet to confirm for myself if this actually works as described.

u6zk6
  • 1
  • 1
  • I can confirm that in RSA 9.1 most of the embedded source is left intact with some minor exceptions like less-than '<' and a few other characters that unless HTML-encoded would prevent parsing of the XML document. Importantly the linefeeds are proper 0xA linefeeds. Overall I and most of my colleagues think RSA sucks big time and can't wait for the day when it will be consigned to the scrapheap it belongs to. – u6zk6 Apr 03 '15 at 10:00
  • far too complicated. just use svn. git is for **source code text files**. – Fattie Jun 26 '16 at 01:46