Implementing Version Control In Applications

Contents

• 117.1 Introduction
• 117.2 Applications with no need to maintain legacy behaviour
• 117.3 Applications with legacy data created in applications that only use the consolidated system
  • 117.3.1 Creating new features
  • 117.3.2 Updating features
• 117.4 Applications with legacy data created in applications that implement both the consolidated and the original systems
  • 117.4.1 Creating new features
  • 117.4.2 Updating features created since implementing the consolidated system
  • 117.4.3 Updating features created before implementing the consolidated system
• 117.5 A detailed example of the consolidated system

[back to top]

117.1 Introduction

This chapter provides advice on how best to implement version control in your application, using a combination of the consolidated system and the original system, depending on your needs.

• Section 117.2 describes what you should do if you never have to deal with legacy data.
• Section 117.3 describes what you should do if you only have to deal with legacy data created in an application that implements the consolidated system.
• Section 117.4 describes what you should do if you have to deal with legacy data created in an application that implements both the consolidated and original systems.
• Section 117.5 provides a complete worked example of how you can use the consolidated system to maintain legacy behaviour to minimise the possibility of regressions during version updates.

[back to top]

117.2 Applications with no need to maintain legacy behaviour

The most straightforward situation is if your application never needs to emulate the behaviour of an older version of Parasolid. In this case, you can just instruct Parasolid to always use the latest behaviour. Do this as follows:

This ensures that for the remainder of the session, the latest behaviour will be accessed at all times.

[back to top]

117.3 Applications with legacy data created in applications that only use the consolidated system

If you need to maintain legacy behaviour in features created in applications that only implement the consolidated system, you should use PK_SESSION_set_behaviour to set behaviour appropriately when creating new features and when updating existing features.

117.3.1 Creating new features

When creating new features in your application, you need to ensure that you always use the latest behaviour offered by Parasolid. In addition, you need to store details about the version of Parasolid that new features are created in. Do this by performing the following workflow for each new feature that you create:

117.3.2 Updating features

When updating existing features, you need to check which version of Parasolid the feature was originally created in, and then emulate that version of Parasolid. Do this as follows:

This last step ensures that as you continue to create new features, old behaviours do not remain set and Parasolid does not access legacy behaviour by mistake.

[back to top]

117.4 Applications with legacy data created in applications that implement both the consolidated and the original systems

The most complex situation is when you need to maintain legacy behaviour in features created in applications that implement both the consolidated and original systems, since behaviour may need to be preserved using either session behaviours or a combination of session switches and update switches. To minimise the code changes you are required to make in this situation, the general approach is to consider the original system as your “default” system, and activate the consolidated system only when creating new features or updating more recently created features.

The key to implementing this system is to return the session behaviour to its initial value of PK_SESSION_behave_as_unset_c to ensure that older features can continue to be updated successfully using the original system.

This section explains how to implement such a system.

117.4.1 Creating new features

You should create all new features using the consolidated system. Do this as follows:

This last step ensures that the new mechanism is not active when you update features built in the original system. This is necessary to ensure that these features continue to update correctly, without you needing to make changes to your application code.

You can start using the consolidated system in any release of Parasolid from V28.1 onwards. Session switches and update switches will continue to be supported so that you can make the transition at any later version.

If you cannot adopt the consolidated system immediately, continue to use the original system for creation and update of features, and store the same information as before in the feature data.

117.4.2 Updating features created since implementing the consolidated system

To update existing features created since you implemented the consolidated system, you need to use the consolidated system to emulate the relevant Parasolid release, and then return the Parasolid session to using session switches and update switches. Do this as follows:

117.4.3 Updating features created before implementing the consolidated system

To update existing features created before you implemented the consolidated system, set session switches and update switches to the appropriate values based on the feature data already stored. This requires no changes to your existing version control architecture for updating features that were built when the original system was the only version control implementation.

[back to top]

117.5 A detailed example of the consolidated system

Unless your application has absolutely no requirements to maintain legacy behaviour, you are recommended to always rebuild features using the same behaviour as was available in the Parasolid version you used when you created the feature. Doing this ensures that downstream operations are never adversely affected by improvements in Parasolid's behaviour. This section describes a straightforward example that shows why you should do this and how you achieve it using the consolidated version control system.

Figure 117-1 shows some of the stages in the creation of a sheet metal part.

Figure 117-1 Creating features in an application without version control

Part A shows the result of extruding a profile into a solid. Notice how, in this example, Parasolid has created a redundant vertex when drawing the circles in the profile. This has then been extruded and created a redundant edge.

Part B shows the part after further modelling has been performed. Blends and other small features have been added and the part has been hollowed so as to produce a thin sheet.

Part C shows the result of sectioning this sheet. Note that the user has decided to use the redundant edge created in Part A as the basis for the tool body used in the section operation.

Now suppose that a later Parasolid release improves behaviour such that the redundant vertex seen in Part A of Figure 117-1 is no longer created. Figure 117-2 shows what happens if the part is rebuilt using an application that does not support the consolidated version control mechanism - that is, the application always takes advantage of Parasolid's improved behaviour.

Figure 117-2 Failing to rebuild features after improvements to behaviour

Part A shows the same extruded profile, but, as expected, no redundant topology is present because the part has been rebuilt in a version of Parasolid that uses the improved behaviour.

Part B shows the hollowed, blended model, again without any redundant topology.

At some point after this, the rebuild fails. The application attempts to create the tool body for the section operation, but because the redundant edge no longer exists in the part, it cannot complete the operation.

In order to protect against this type of situation, you need to use the consolidated version control mechanism to record the build in which a feature was created, and then ensure the same behaviour is used whenever the feature is rebuilt. You do this as shown below.

Figure 117-3 Creating features in an application with version control

Figure 117-3 shows the same modelling steps as Figure 117-1. However, this time the modeller makes a call to PK_SESSION_set_behaviour before starting to model the feature, with the following arguments:

behaviour_requested.behaviour_type

behaviour_requested.behaviour_value

behaviour_set.behaviour_type

behaviour_set.behaviour_value

This ensures that you have a record of the version of Parasolid that was used to create the feature.

Next, Figure 117-4 shows what you need to do in order to replicate this behaviour when rebuilding the part in the later Parasolid release that no longer creates the redundant vertex.

Before rebuilding the part, call PK_SESSION_set_behaviour with the following arguments:

behaviour_requested.behaviour_type

behaviour_requested.behaviour_value

This will ensure that the part is rebuilt using the behaviour offered by the Parasolid version originally used to build the part, and in particular ensures that the redundant vertex is present in the initial profile (Part A). Modelling can continue as shown in Part B, and the section operation shown in Part C succeeds.

Once the feature has been rebuilt successfully, you should "reset" your Parasolid session to use the latest behaviour again, by calling PK_SESSION_set_behaviour one last time with the following values:

behaviour_requested.behaviour_type

behaviour_requested.behaviour_value

Figure 117-4 Successful rebuild of features after improvements to behaviour

[back to top]