Question
Achmea
NL
Last activity: 8 Jan 2020 8:52 EST
Branching in Robotics
Hello,
In our team of Robotics developers we are working with some big solutions. For this it would be very nice to work with branches, so several people can work on different parts of the solution at the same time and merge the work. Is this possible with Robotics?
thank you
-
Like (0)
-
Share this page Facebook Twitter LinkedIn Email Copying... Copied!
Boubyan Bank
KW
If you are using Visual studio plugin , then it can be integrated with any compatible source control , ex: bitbucket, TFS etc
If you are using studio, then it can be done by Folder level SVNs ( like tortoise SVN , else source Trees )
It is advised to used integrated version control, since at the time of accumulation of all projects/automation/codes , there is a high possibility of code correction. additionally this saves the time and hassle of code integration
Achmea
NL
Thank you for the answer
Achmea
NL
Thank you for the answer
Pegasystems Inc.
US
We do not recommend merging due to the way the .os files are constructed. We recommend using a source control provider that allows for exclusive file locking so that only one person can modify a file at a time. I have had the best success with SVN and it works with both the Studio plugin and standalone Studio since it is file/folder based.
When using a source control provider there are several very important things to be careful with. Controls and automations and even projects have names but are internally managed using system generated Ids. So, when 2 developers add an automation to their copy of the project with the same name they will each have a different Id, meaning they are not the same object. So, commonly used objects should be kept in central locations - for instance all global variables should be kept in a global container. When a new global variable is added, the file will be locked, the variable added and everyone will be instructed to refresh their copy of the global container. Same for adding automations to a project, changing an adapter and so on.
Using care and communicating when major changes are made will prevent issues.
We do not recommend merging due to the way the .os files are constructed. We recommend using a source control provider that allows for exclusive file locking so that only one person can modify a file at a time. I have had the best success with SVN and it works with both the Studio plugin and standalone Studio since it is file/folder based.
When using a source control provider there are several very important things to be careful with. Controls and automations and even projects have names but are internally managed using system generated Ids. So, when 2 developers add an automation to their copy of the project with the same name they will each have a different Id, meaning they are not the same object. So, commonly used objects should be kept in central locations - for instance all global variables should be kept in a global container. When a new global variable is added, the file will be locked, the variable added and everyone will be instructed to refresh their copy of the global container. Same for adding automations to a project, changing an adapter and so on.
Using care and communicating when major changes are made will prevent issues.
Merging just is not practical since each automation contains so much information that may change when the automation is opened by another person. Each block and each line have coordinates telling Studio how to draw the automation and those changes between developers can create hundreds of merge conflicts on a single .os file. This makes it very difficult to tell what the real change was and the main reason for avoiding merges.
Achmea
NL
Thank you for your answer. It's not an ideal working situation.
Is it correct that in the Pega Infinity release there will be a better option in working in branches?
Pegasystems Inc.
US
Building upon what Jeff said, we also suggest that you assign developers to different projects within the solution. This prevents them from having much of anything to merge. We usually setup each project as its own "logical" container; meaning its own collection of one "piece" of the solution. This is usually a specific adapter. When you assign a developer to work on automations for a specific adapter, they acquire the expertise with that application and begin to understand how the application works and how the controls need to be matched. These are things outside of any functional documentation and get acquired through experience with the application. Having a developer who's an expert on a specific application makes their job that much easier.
The developer who creates the "controller" project for the solution just needs to know which automation to use within the adapter projects which can be agreed upon in advance (i.e. what the inputs/outputs are).