We received outstanding feedback and a lot of interesting questions during our recent webinar!
Thank you for your interest!
All of the FAQ can be found on our help page
Start with LemonTree today and get your free trial!
And here are the questions and answers from during our Webinar:
Question: Where can I see which branch was checked out?
Answer: The selected branch is “greyed out” in the LemonTree addin menu.
Question: About the LemonTree integration with EA: it’s the first time I see this menu in a presentation. Is it already part of LemonTree? Is it another addon?Where can I find it. I only use LT from Tortoise as of now.
Answer: The LemonTree Addin is part of the LemonTree setup (2.5 and higher)
Question: Can code base (e.g. Visual Studio Solution) and model be held together in the same GitRepo?
Answer: Yes. This is one major advantage of this approach.
Question: Would GIT be able to resolve this automatically when you’d checking MPMS exports instead eap files?
Answer: If you have separated MPMS, the behavior is similar, because it has to be prevented that a text-based merge tool is touching the MPMS files. Completely automatic merge is possible when hooks are defined within the Git client.
Question: All files are stored as binary? hence every commit (change) is a copy of the binary. what about the size of the git repo after all this commits, i guess it is getting huge?
Answer: We suggest to use the Large File Storage extension for Git. Here, only pointer references are committed. Please see: https://git-lfs.github.com/
Question: Why zooming is improportional in three views?
Answer: Typically zooming is in sync in all views of the diagram viewer.
Question: Is there a visual indication in LemonTree showing what A and B refer to? (= what branch)
Answer: LT can be configured to show the revision for the A and B Model, using the yrev and brev parameters. Installing the Tortoise integration of LT already handles this. The revision is shown in the header and tooltip of the corresponding view in LT (above the model tree).
Question: Why is the diagram shown as conflicted. the diagram itself has been only modified in B?
Answer: The diagram is shown as conflicted because the diagram representations, which are sub-objects of the diagram, have been modified (i.e. there Position has changed). This would be visible when expanding the diagram in LT where it would Show the corresponding element and diagram representation.
Question: Where was the confirm of the change and one conflict was still shown at the upper left corner?
Answer: Changes in LT are confirmed once at the end by selecting Merge which applies these changes. The number of conflicts does not update as LT does not know when a conflict has been fully resolved. However, you can use the review checkmarks and Filtering Impacted Elements / Impacted Diagrams functionality to hide elements which caused a conflict but have been reviewed already.
Question: In the merge-window: is there a possibility to list all conflicts and which of them are already resolved?
Answer: There is a preconfigured filter to show only conflicted elements. You can use the check marks next to the elements in the “List of Impacted elements” and combine both filters:
#Conflicted AND NOT #Reviewed
Question: Are you thinking about (or planing) offering Lemon Tree for Cameo Systems Modeler?
Answer: From a technological point of view, LemonTree middle ware is designed to be used in a tool independent way. However, technological challenges are usually the smallest challenges. (Zwinkern)
Question: When I was evaluating LemonTree in the past, I observed that obvious changes could be merged easily. But I really struggled getting a good overview of the changes in diagrams. How would I deal with that? Could you demo this?
Answer: We’ve introduced advanced filter mechanisms to support users in getting a better overview of all changes. We can show you the possibilities in a web meeting!
Question: What is your recommendation if we have several “long living” feature branches. Regularly merging the develop into the different branches or making “rebase”-branches based on develop and merging the original feature branch onto the new “develop” base?
Answer: It is hard to recommend one approach over the other, as the answer depends a lot on the way modeling is done as well as the structure of the model and the nature of these feature branches. However, rebasing your feature branches often reduces the time between the change and the (potential) merge of this change into your main branch. As such, resolving conflicts tends to be easier when doing the rebases often. Related to that, in general we recommend squashing of the feature branch before doing a rebase if possible, as it reduces the number of required merges and therefore the time it takes to do the merge.