Has anyone been able to collaborate on a model, with 1 other colleague, without “Team for Capella”?
We are a small company looking to collaborate on system models. We tried using a SharePoint library, sync’d to desktop, with the expectation that users can share the Workspace. The intent was that 1 person will make their changes, save and exit, and another user could do the same. This seemed like a really basic ask.
However, there’s something about Eclipse Capella which is making this difficult. Models from other people show ‘Invalid Representations’.
Out of the gate, we looked into Team for Capella, but didn’t like it for many reasons, e.g.
far too expensive for what it is, and too expensive for us.
was only a partial solution, not providing storage, not providing versioning/baselining/configuration management, and still requiring some storage solution and Git, and requiring a configuration manager.
We are a startup, and will not have the luxury of a configuration manager. We don’t have any person that can do configuration management tasks across all projects. The tools should handle versioning with a simple workflow for the project’s systems engineer.
Only our software engineers know Git; we don’t want any other stakeholders to have to learn Git.
We don’t necessarily need simultaneous collaboration. We have only a small number of systems engineers and can easily manage editing one-at-a-time.
For these reasons and more, Team for Capella is not interesting to us.
Does anyone have success using a cloud-based repository for a shared workspace? Or even a local file server? Conversely is anyone else in the same boat as us and looking for a way to collaborate without ‘Team for Capella’?
There is not “something about Eclipse…” there is something about Sharepoint(!) (btw not a good idea for anything…)
Use git for your usecase - you only have to learn to commit, push and pull and keep a repo on your fileserver (or somewhere in the “cloud” if you are more risk-loving ).
And you can have versions, baselines, backup, branches, …
If you fragment your model your systems engineers can even model at the same time as long as they work on different fragments.
I guess in my mind, the Capella model is like any other file - say a .png (or a small set of .png files). From a sync’d SharePoint library, anyone can open a .png in paint as if they were opening it locally, make their changes, save and exit. Within 1 second, someone else can open the .png on their own PC, and make additional changes, save and exit. I am learning that Eclipse Capella is not able to function like that.
In my company we are using a git repository to collaborate on the same Capella project. Some conduct rules should be put in place in order not to generate merge conflicts, but it works.
Of course Team4Capella would simplify very much collaboration.
I’m looking into a Git repository. Our software team already uses Bitbucket. First hurdle is learning to use it. Our SE’s aren’t from a SW background and so I expect nobody using Capella has used git based repositories before.
It’s hard to justify the thousands of Euros on Team for Capella, when the key capability seems to be just simultaneous edits on a model, which we might want but we don’t need… when it doesn’t actually solve the homework problem; for that we still need a solution like a git based repository and configuration management processes. Team for Capella thus does not simplify the implementation.
Not a real problem though is it? Just nudge everyone to use 7.0.0 with the Requirements Addon. Or share the portable app folder with dropins preconfigured. I don’t envisage any trouble.
As long as your are a small team with good communication working together with a git repo is perfectly ok (a little model-fragmentation and a “config-Manager” with an eye on the model will do…).
But when your project and team becomes more complex/large and you want to live the idea of modelling together you will need capabilities of a tool like Teams4Capella.
Modelling together at the same time is only one aspect. You will need access rights, change history and many more.
Hi,
We worked concurrently on the same model. The key is to focus on different parts of the model that don’t interfere with each other. It also helps to disable automatic refresh of representations and to use the same resolution and magnification settings for the display. This is because refreshing a representation can generate hundreds of differences in the .aird file.
Based on our experience, the most effective workflow is as follows:
Pull from origin to update the local master branch from the remote repository.
Create and switch to a new local branch.
Make your local edits.
Commit changes to the local branch.
Switch back to the master branch.
Pull from origin again to ensure the local master is up to date.
Merge the local branch into the local master.
Push changes to the remote repository.
It’s important to repeat this process frequently to minimize the risk of diverging changes due to concurrent modifications.
Conflicts may still occur. In such cases, use the diff/merge tool to resolve them.
we have a fragmentation of the model into several different topics
we work on topic branches, only fragments of the topic shall be modified on this topic branch
our “config manager” merges the topic-branches frequently into the main branch
changes on a higher level than the topic branch shall only be done in agreement with the “config manager” and where appropriate with the other affected topics.
conflicts are solved with the diff/merge-tool or by a textual merge of the xml-files.
We faced several challenges but until now we were able to avoid to discard/step-back of topic-branch changes.
).