Merge feature explained

Purpose: Allow more than one person to design for the same Stadium application at the same time

Scenario:

Okay, so you are at this major corporate and an application on Stadium3 has just gone live. However you still have to add new pages, make changes for the next version of the same application and you have a team of six implementers.  There is a lot of work to do and all the six implementers need to start implementing the changes, there is one set of files i.e. sap and config file for the application. How do you do this?

Definitions:

Master file: The Stadium application file from which merge feature will be triggered.

Source file: The Stadium application file with the changes, these changes need to be merged with the master file

How:

• The starting point is the sap and config file of the application in production, in this scenario this is the ‘master’ file.
• Each  implementer needs to copy both the master sap and config files, the copied files are the ‘source’ files
• Open the source application in the designer
• Make the necessary changes/additions and save
• When finished open the master application
• Click on Merge toolbar button on the master application
• Select the source stadium application as the file to merge
• The merge dialog will highlight the new/modified entities
• Select the entities you have changed
• Save the changes
• Notify the rest of the team you have updated the master file
• Each team member now needs to update his/her application file with the changed master file. In this scenario each member’s file becomes the master file and the master file the source file.

Please follow below suggested best practices:

• All components should be named as per their function e.g. if a page displays a list of users, give it a name to indicate the same, do not keep the default name e.g.’ Page10’
• After merging the changes with the master application, let other team members know that it has been updated. It is ideal that they merge the changes with their local sap files as soon as possible. This way the changes are kept minimal and there is less likelihood of clashes occurring.
• A page is regarded as the smallest unit of work. If two implementers work on the same page, only changes made by one of them can be maintained. It will best to split the work on a page by page basis.
• If an entity is deleted in the master file and not in the source file, when merging, it will appear as a new file as this entity does not exist on the master file.  It will be best deletes are communicated to team members.