Kbase P25218: RoundTable. SCM integration incomplete.
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
15/05/2003 |
|
Status: Unverified
FACT(s) (Environment):
RoundTable 9.1x
FACT(s) (Environment):
Dynamics 2.0A
SYMPTOM(s):
RoundTable. SCM integration incomplete.
CAUSE:
Only a limited set of object types is handled automatically by the SCM hooks. Some files are not deployed automatically to the other workspaces. Samples: object types (GSCOT), error messages (GSCER), menu items, structures, tokens.
FIX:
This issue is being seen as a result of limitations in the general dataset and deployment functionality in Dynamics. It is not specifically related to the RTB and Dynamics integration. RTB does make the handling of datasets with data for the static data easier, as they are included in the deployments that are being sent between the development sites.
The main difficulty, which is also giving the manual effort for Cargomate and other users, is the creation of the physical dataset files with the data from the Dynamics repository. Once these are created, managing them in RTB certainly
does help the management of this data. I understand from Bruce that there are a number of improvements planned in this area for filtering data to deploy, as well as making incremental deployments of data.
There is also an option to try and enable automated SCM control for other data than dynamic objects. This may be possible through data set-up with the Entity Mnemonic table making it possible to version control individual sets of
data like menu items in exactly the same way as we version control dynamic objects at the moment. I will look into what is involved to enable this. You would not want to do this for all sets of data though - as it does not always make sense to be versioning individual records for all tables.
There are the following option:
- Instead of manually filtering just their own data or the data that they have changed, they should look into making deployments of ALL of the data in the tables they are transferring, This is both faster to do, but also ensures that the data that we are actually handing within RTB is a full set of data that can also be used to generate full sets of data from a deployment when they use deployments to create completely new application installations. If they are only using incremental data, then the .ado files coming from RTB will never be sufficient to create a new application install.
The main downside of this solution will be handling conflicts where the same data has changed in both of their development sites. Here some sort of conflict resolution is needed to prevent changes from being lost. This needs to be
looked into to ensure that Cargomate do not lose any data.
Unless the data conflicts becomes a problem, the transfer of larger amounts of data between the development sites is both easier to handle and creates a more complete set-up in RTB.
Martin would like to have an idea of when changes to the deployment and dataset functionality are expected to be released. As they involve schema changes and new or changed tools, they can only be expected as part of a commercial release.