Discussion Boards > Archi Development

Contributing to the new Model Repository Plug-In

(1/5) > >>

JonSykes:
Hello all!

This is my first time posting here, but I wanted to introduce myself at least. I am an Enterprise Architect based out of Florida and my team has started to do our modeling exclusively using Archi. We are currently working through our workflow on collaboration and decided to take the new Model Repository Plug-In for a spin. I think it is a good foundation to make a really great collaboration tool.

So I have a few questions... I have reviewed the plug-in code and reviewed a lot of the code around Grafico as well.


* Is there a feature on the road map to implement branching/branch selection?
* I know there is a feature on the road map to handle conflicts on merges, but how have others handled conflicts on merge up to this point?
* This is more of a general (non-technical) question. How have others decided to handle future state in their models?
* Can we help contribute to development on items 1 and 2?
We have some free cycles and are experienced Java developers, so we would love to help contribute to the plug-in as it would benefit our team greatly.

Thanks for your time fellas!
Jon

Phil Beauvoir:
Hi Jon,

welcome to the forums and thanks for your offer of help.

1. Yes - but first we need a better History View to manage potentially big history lists and the branching UI. jGit has an API to handle this and it is implemented in eGit (git client in Eclipse). I tried to reverse engineer it to extrapolate extricate it from the clutches of the Eclipse SDK but failed to do so. ;-)
2. There is some conflict management already. If you are seeing specific conflict types that are not presently handled you could report them here - https://github.com/archi-contribs/archi-modelrepository-plugin/issues
3. I can't answer that as I don't know
4. Yes please - see my responses above...

Phil

JonSykes:
Awesome I would be happy to help tackle the branching feature.

So in regards to branching and the Change History, my guess is you would want a way to display history by branch? is this what you were referring to by a "better History View"?

Are there additional issues with the History View when the change log gets large?

I will take a look at eGit to see if I can determine what you are talking about as well. :)

Phil Beauvoir:
- In Archi we use the jGit library to do the git-based heavy lifting and connect to a git API - https://www.eclipse.org/jgit/

- There is also an eGit plugin for Eclipse that provides a UI and integration with Eclipse. This sits on top of jGit. It also has a History view that can display branches and tags:



- We can use jGit to take care of actually creating and managing branches but we definitely need that History view in order to see what's going on. The problem is that it so heavily integrated into the Eclipse SDK API that you would bring in a ton of baggage if you tried to use it as-is (Eclipse resources, listeners, properties, you name it...)

> Are there additional issues with the History View when the change log gets large?

Yes. My current implementation is just a dumb table that loads in all commit entries. If the history log is big, this will choke the system. The eGit History view does some fancy lazy loading.

One thing we're trying to do is to protect the Archi user from having to have too much Git fu.

Phil

JonSykes:

Got it.

Let me see what I can do, might be able to take some of this load off. :)

Navigation

[0] Message Index

[#] Next page

Go to full version