EAE-MS SCCAPI based Version Control System

(1)

Using Version Control

EAE-MS SCCAPI based Version Control System

This document is an implementation guide to use the EAE-MS SCCAPI based Version Control System as an alternative to the existing EAE Version Control System. The support for an EAE-MS SCCAPI based version control system via SCC API in EAE is implemented in a phased manner.

This guide assumes you to have basic knowledge of EAE and a clear picture of the existing EAE Version Control System that is based on the UREP Version Control System. This helps you to understand the EAE-MS SCC API based Version Control System better.

You must install EAE along with proposed Version Control System. The document explains the various tasks related to Developer version control, which are as follows:

 Installation of the Version Control System  Administration of the Version Control System  Use of the Version Control System

Overview of Version Control

Version Control is an optional Developer feature that provides source control of versionable Enterprise Application objects such as Model definitions, Data

dictionary items, Ispecs, Profiles, and Reports. Version control stores each version of an object so that you can access and use earlier versions if required.

The hub of Version Control is the Version Control Bank. The Version Control Bank is file storage facility that holds controlled copies of objects, but it does not replace the Developer Repository. The Version Bank supports source control services, such as locking and maintaining the history of an object, while the Repository functions as a work area where copies of the controlled objects are modified and tested before being moved back into the Version Bank.

Versionable objects in the Developer Repository are not automatically protected by Version Control. You must add the objects to the Version Control Bank. You can add individual object, or you can add a group of related objects using container operations.

Once the object is added to the Version Control Bank, you can modify that object and keep track of its revisions. You can achieve this using the Check Out

operation. The object is then locked under your userid in Version Control.

Once the modifications/updates on to the Checked Out object have been finished, then we can perform CheckIn operation on that respective object. When you Check In a modified object, a new revision or version of the object is created in Version Control and the respective object are unlocked and the object is available for the further operations.

(2)

You can also perform “Get Latest Revision” operation to get the latest version of an object from the version control into the Developer Repository. The copy of the object present in the Developer Repository is replaced by the latest copy of the same object from the version control. Version Control also allows us to ‘undo check out’, unlocking an object without checking it in.

Existing Version Control System

The existing EAE version control system was specifically designed for EAE using universal repository (UREP) as the repository to store the versions. And, all the source control operations were controlled by EAE Developer.

To use EAE Version Control System, you are expected to have EAE version control server installed on the VC server machine and install EAE Developer along with VC client by providing the necessary details to connect to VC server. You would then be enabled a version control menu option to perform VC operations.

EAE-MS SCCAPI based Version Control System

EAE-MS SCCAPI based VCS are designed to provide you an option to choose the VCSs that are compatible with MS SCCAPI. The design of EAE-MS SCCAPI has no dependency on the existing Version Control System. It does not expect existing version control client/server to be present to work successfully. The following is the design of EAE-MS SCCAPI based VCS:

Although, there is no restriction or rules for modifying the Version Control Bank directly outside the Developer, it is not possible to secure the Version Control Bank from unauthenticated changes or data corruption from the source control provider side.

(3)

Note: It is recommended not to make any changes directly in the temporary

work Directory and to maintain the synchronization between EAE Developer Repository and Temporary Working Directory.

Setting up EAE-MS SCCAPI based VCS

Software Requirements

The following are the software required to setup EAE-MS SCCAPI based VCS: 1. Enterprise Application Environment

2. Version Control Systems

3. Source Control Provider that is compatible with SCC API Setting up EAE-MS SCCAPI based VCS for SVN

This section explains how to configure EAE-MS SCCAPI based VCS using SVN VCS. Step 1: Install EAE.

Step 2: Install SVN server.

Step 3: Install PushOKSVN source control provider. Step 4: Install TortoiseSvn client

PushOKSVN provides an SCCAPI interface. There is no graphical user interface provided by PushOKSVN. You must install Tortoise SVN Client to browse through the contents of the source control bank and perform user related operations like viewing the mdl files of various versionable objects.

Step 5: Create SVN repository and sync it with the Work directory to be used as VCLocalTempPath

Step 6: Set the following LINC.ini options under [Version Control] section:  EAEMSSCCAPIVC

 VCProjectName  VCProviderDLLName  VCAuxillaryPath  VCLocalTempPath

Step 7: To configure the SVN to view the contents of the mdl files from the source control client before the Check In operation, refer to section Viewing the Content before the Check In using Source Control Client (SVN).

(4)

Step 8: To configure the SVN to view the differences in the mdl files from the source control client before the Check In operation, refer to section Viewing the Content before the Check In using Source Control Client (Clearcase).

Setting up EAE-MS SCCAPI based VCS for Clearcase

This section explains the procedure to configure EAE-MS SCCAPI based VCS using ClearCase VCS.

Step 1: Install EAE (Single User Mode/Multi user Mode with or without VC Client). Step 2: Install ClearCase Client

Step 3: Create ClearCase VOB and Base ClearCase view to access it. Step 4: Set the following LINC.ini options under [Version Control] section;  EAEMSSCCAPIVC

Step 5: To configure ClearCase Explorer and view the contents of the mdl files from the source control client before the Check In operation, refer to section Viewing the Content before the Check In using Source Control Client (SVN) for more information.

Step 8: To configure ClearCase Explorer and view the differences in the mdl files from the source control client before the Check In operation, refer to section Viewing the Content before the Check In using Source Control Client (Clearcase) for more information.

Setting up EAE-MS SCCAPI based VCS for Team Foundation Server (TFS) Perform the following steps to set up EAE-MS SCCAPI for TFS.

Step 1: Install EAE (Single User Mode/Multi user Mode with or without VC Client). Step 2: Install Visual studio Team Foundation Server explorer (VSTS).

Step 3: Install Microsoft Team Foundation Server MSSCCI Provider.

Step 4: Locate the installed path of tf.exe and include it in the path variable. Note: Generally the path is available at the following location:

(5)

Hence add the above line into the path of the environment variable.

Step 5: Create theTFSrepository and sync it with the Work directory to be used as VCLocalTempPath.

Step 6: Set the following LINC.ini options under [Version Control] section;  EAEMSSCCAPIVC

Basic Operations in EAE-MS SCCAPI based VCS

Adding Element(s) to Version Control Bank

You can add any versionable object to the Version Control Bank. To add an individual object or objects:

1. Click on the object(s) in the Model directory to select it.

2. Select the Add Element(s) to Bank command on the Version Control menu.

Note: If this command is not available or disabled, the object you have selected

is either not versionable or has already been added to the Version Bank.

Checking Out an Element

Checking out an element locks the object to be modified or updated and does not allow any changes from others on the same object.

To check out an element:

1. Select the object in the Model directory.

2. Select the Check Out command on the Version Control menu. 3. Check Out command will get the latest version of an object into the

developer repository from the bank and the object gets locked.

is either not versionable or has not yet been Added or Checked In to the Version Bank.

(6)

Undoing a Check Out

You can use the Undo Check Out command to unlock objects that were

previously checked out from the Version Control Bank that is, to reverse the Check Out operation.

To undo a check out:

1. Select the checked out object in the Model directory.

2. Select the Undo Check Out command on the Version Control menu. 3. The object will be reverts to the previous state as it was before the Check Out

operation the object is unlocked.

is either not versionable or has not yet been Checked Out from the Version Bank.

Viewing the Difference before Performing Check In from the Developer After the modification you can see the difference between the object that has been modified with the latest version of the same object in the bank using the LDADiff.js script provided.

You can perform the following steps to view the difference:

Before performing the Check In command, if the object in the Developer

repository is different from that of the bank, please perform the following steps to view the difference.

1. On the Tools menu in Developer > Show differences, select the respective object from the repository and the LCIF file of the same object by browsing to the path mentioned in VCLocalTempPath to view the difference. 2. Perform the Check in command.

Viewing the Content before the Check In from the Command Prompt You can view the contents of the version able object by running the LDAView.js script file from the command prompt. Perform the following step:

Run the LDAView.js script as shown in the below screenshot:

Note: Open the LDAView.js file and make sure that the LINC.INI is mapped

(7)

Viewing the Differences before the Check In from Command Prompt

You can view the differences in the version able object by running the LDADiff.js script file from the command prompt. Perform the following step:

Run the LDADiff.js script as shown in the below screenshot:

Note: Open the LDADiff.js file and ensure that LINC.INI is mapped

(8)

Merging Two Files before the Check In from the Command Prompt You can merge the two model files of a version able object by running the LDAMerge.js script file from the command prompt. Perform the following step: Run the LDAMerge.js script as shown in the below screenshot

Note: Open the LDAMerge.js file and ensure that the LINC.INI is mapped

(9)

Viewing the Content before the Check In using Source Control Client (SVN) You can view the contents of the versionable object by performing the following steps using TortoiseSvn client of Subversion as an example:

1. Locate the versionable object mdl from the source control tool explorer. 2. Right-click the .mdl file and select open with option > browse to the path

where LDAView.bat is available, select the .bat file, and click open. 3. You can now view the .mdl file contents.

Note: Open the LDAView.bat file and ensure that the absolute path this file is

(10)

Viewing the Content before the Check In using Source Control Client (Clearcase)

1. Open the Rational Clearcase Explorer. 2. Browse and select the file to be opened.

3. Double-click (or right-click) the file, and then select Open with. In the Open with dialog box, browse and select LDAView, and then click OK.

Viewing the Differences before the Check In Using Source Control Client You can view the difference before performing Check In by performing the following steps using TortoiseSvn client of Subversion as an example:

1. In the TortoiseSvn settings > point to External Program > Diff Viewer. 2. Select External under Configure the program used for comparing

different revisions of files section. 3. In the Advanced tab, click Add button. 4. Select Extension or mime-type as .mdl.

5. External Program wscript.exe “<Absolute path of the LDADiff.js script file>” %base %mine.

6. You can view the differences in the revisions of the versionable objects by right clicking on the object and clicking show log.

7. Select the different revisions of the same object.

8. Right-click and use Compare Revisions to view the differences. For Example:

(11)

Note: Open the LDADiff.js file and make sure that the LINC.INI is mapped

appropriately.

Checking In an Element

Checking In an object creates a new version of the selected object in the Version Control Bank from the Developer Repository.

To check in an object:

1. Select the checked out object in the Model directory.

(12)

is either not versionable or has not yet been Checked Out from the Version Bank.

Getting the Latest Revision from Version Control Bank

Getting the latest revision of an object moves a copy of the most recent revision from the Version Control Bank into the Developer Repository.

To get the latest revision of an object:

1. Select an object from the Model directory.

2. Select the Get Latest Revision command in the Version Control menu. Get Latest Revision Container Operation

Before performing the Get Latest Revision using Container operation, ensure that the temporary working directory is in sync with the Version Control Bank. Refer to section 7.4.6.

To perform Get Latest Recursive Operation of a folder object: 1. Select the folder object in the Model directory

2. Select Get Latest Container Option

Other features

The features that are provided in Phase-II are 1. Enforce Integrity

2. History Explorer Enforce Integrity

Enforce Integrity option ensures the user in maintaining synchronization between the versionable objects that are present in Developer repository with the objects in the version control bank. The Enforce Integrity option is available to the users in the form of check box in the SCC API Version Control Options dialog box.

Individual Version Control users can set Integrity Management for their own workstations by selecting the Enforce Integrity check box in the Version Control Options dialog box.

(13)

When you select Enforce Integrity,

1. You cannot modify the versionable objects that were checked into the bank. 2. You are allowed to modify the versionable objects only when the versionable

objects are check out from the version control bank. 3. You are restricted in performing the load operation.

Load operations are not allowed when Enforce Integrity is selected because they affect the contents of the Developer Repository which will make the Developer repository not in synch with the server repository.

To perform a load operation, you must consider the following settings: 1. Create a Repository for the load

2. Clear Enforce Integrity in the SCC API Version Control dialog Box. 3. Configure the Repository for the load operation.

4. Load your data into this Repository.

5. Check in or add the elements to the Version Control Bank and making them available to users with Repositories in which the Enforce Integrity option is selected. You can now perform the familiar Get or Check Out operations to access these objects in the Version Control Bank.

History Explorer

History Explorer is an independent executable tool which will help the users to perform the below operations.

1. Compare the differences in the revisions of versionable objects. 2. Import a Version Control Bank into the Developer repository.

(14)

3. View the contents of the respective revision of the versionable object

Steps to compare the Two Revisions of a Versionable

Object

1. Run the Register.bat file (Preferably run as administrator).

2. Launch the History Explorer by double-clicking Explore3x.exe (Preferably run as administrator).

3. Provide the contents.xml file that is available in the UREP exported data as an input

4. Select different revisions of the same versionable object and use the compare icon to compare.

Following are the screen shots of comparing the different revisions of a versionable object using History Explorer:

(15)

Steps to Import a Revision from the Exported Data into

the Developer Repository

4. Select the business segment. 5. Click on Import icon.

6. Browse to the EAE installed folder of respective Lincdev.exe to where the bank needs to be migrated and click OK.

Following are the screen shots for importing a Version Control Bank using History Explorer:

(16)

(17)

Steps to View the Content of the Revision from the

Exported Data

1. Copy the Linc.ini file from the work folder to the place where the Lincdev.exe resides.

(18)

Setting an Environment for SVN on Windows Server 2003

for 32 and 64 bit Platforms

To set up the configuration for SVN in Windows Server 2003 Operating System, you need to copy msvcr100.dll and msvcp100.dll, that are available as part of the Hotpatch to the EAE installed folder which will resolve any sort of issues while connecting to the Version Control Bank.

Getting the Latest Revision from EAE VC Bank to EAE-MS

SCCAPI based VCS

You can migrate the repository from an existing Version Control System into EAE-MS SCCAPI based VCS by performing the following operations:

1. Log into VC with the help of appropriate login credentials.

2. Open Version Control Explorer and select the object(s) (business

segments) to be retrieved into the repository. The following screenshot gives a clear picture of the same:

3. Select the Get Latest Revision command in the Version Control menu as shown below to retrieve the objects from the VC Bank into the Developer Repository.

(19)

4. Perform a full extract of the business segment on which Get Latest Revision was done and load the extracted model file into the Developer Repository, where EAE-MS SCCAPI based VCS is setup.

Migrating EAE Developer Repository with EAE-MS SCCAPI

based VCS to another EAE Developer Repository

The following steps enable you to migrate the data from EAE Developer with EAE-MS SCCAPI based VCS to another EAE Developer (Example: Developer to testing environments or Testing to Production environments):

1. Do the “Get Latest” of the business segment using container operations in the Source EAE Developer.

2. Do either a full extract or extract using “Changed Items” option since the last load.

3. Load the extracted model file on to the destination Developer Repository.

More on EAE-MS SCCAPI based VCS Setup Details

LINC.INI Options under VERSION CONTROL Section for SVN

Option Value Description

EAEMSSCC

APIVC N/Y

Indicates if to use existing VCS or EAE-MS SCCAPI VCS. For example, EAEMSSCCAPIVC = Y

VCProjectN

ame String < 256 chars

VC project Name. For example, VCProjectName=projName

(20)

creating in the source control tool.

VCProvider

DLLName String < 256 chars

Name of the Source control client DLL with an absolute path that provides an interfaces to carry out the VC

operations. For example,

VCProviderDLLName= C:\Program Files\Pushok

Software\SVNSCC\PushokSVNSCC.dll.

VCAuxillary

Path String < 256 chars

Version Control Bank path. For example, VCAuxillaryPath =

file:///D:/EAEMSSCCAPIVC/SVNRepos/ BANK (This is the path where the repository is locally created. You can also use the path when remotely created(SVN://<IP address>/BANK)) VCLocalTe

mpPath

String < 256 chars

Path points to local work directory. VCLocalTempPath = C:\TEMP\VC

The following screenshot gives a clear picture of the newly added LINC.ini settings.

LINC.INI Options under VERSION CONTROL Section for Clearcase

EAEMSSCCAPI

VC N/Y

Indicates whether to use existing VCS or EAE-MS SCCAPI VCS. For example, EAEMSSCCAPIVC = Y

VCProjectNam

e String < 256 chars

VC project Name. For example, VCProjectName=projName Name of the project, which you create in the source control tool. VCProviderDLL

Name String < 256 chars

Name of the source control client DLL with an absolute path that provides an interfaces to carry

(21)

out the VC operations. For example, VCProviderDLLName= C:\Program Files\IBM\RationalSDLC1\ClearCas e\bin\ccscc.dll. VCAuxillaryPat h String < 256 chars

For ClearCase, this variable has no effect.

This variable can point to any string

VCAuxillaryPath=demo VCLocalTempP

ath String < 256 chars

Path points to local work directory. VCLocalTempPath = C:\TEMP\VC

EAEMSSCCAPI

VC N/Y

Indicates whether to use existing VCS or EAE-MS SCCAPI VCS. For example, EAEMSSCCAPIVC = Y

The following screenshot provides the details of the newly added LINC.ini settings:

LINC.INI Options under VERSION CONTROL Section for TFS

In order to set the linc.ini file, add the following options to the linc.ini Version Control section:

EAEMSSCCAPIVC N/Y

Indicates whether to use existing VCS or EAE-MS SCCAPI VCS. For example, EAEMSSCCAPIVC = Y VCProjectName String < 256 _chars VC project Name. For _example,

(22)

VCProjectName=projName Name of the project which you will create in the source control tool.

VCProviderDLLNa

me String < 256 chars

Name of the source control client DLL with an absolute path that provides an

interfaces to carry out the VC operations. For example, VCProviderDLLName= C:\Program Files\Microsoft Team Foundation Server MSSCCI Provider\ TfsMsscciProvider.dll.

VCAuxillaryPath String < 256 _chars

Version Control Bank path. For example, VCAuxillaryPath = VCAuxillaryPath =http://ustr-r1t8s28:8080/tfs/tfsformanoj VCLocalTempPat h String < 256 chars

Path points to local work directory. VCLocalTempPath = c:\tmp\tfs8

Using the GUI to Set LINC.ini options

To perform the same above linc.ini settings, their also exists the GUI and these options can be set using this GUI anytime. The below screen shows the GUI to set all the four linc.ini options. The options set using this GUI will also be reflected in the linc.ini file.

(23)

Creating Repository and Synchronizing it with the Local Work Directory of SVN

Before doing any further operations, the repository needs to be created at the location mentioned in the LINC.ini option of VCAuxillaryPath using the Create repository here option as shown:

(24)

As mentioned in the following screenshots, the Repo-browser needs to be selected from the work folder that is mentioned in the VCLocalTempPath setting to check if the path mentioned in the URL is pointing to the appropriate bank or not. This bank path should match with the VCAuxillaryPath setting of the LINC.ini file.

(25)

Now, to ensure that the work folder and Bank are in sync with each other, you can perform the following simple exercise, which confirms that the environment is setup properly to go ahead with VC operations.

(26)

As the work folder and the Bank are in sync now, you can proceed with the VC operations.

Synchronizing the Local Work Directory with the Server in TFS

When you login to the server, the command "tf get" is executed and prompts for your userid and password. You have to provide the userID and the password every time you login to the server. To avoid providing the details every time, the UserID and the Password details is maintained in eaesync.bat file, which is taken into consideration during the synchronization.

(27)

VC Operations with EAE-MS SCCAPI based VCS

Add Element(s) to Bank

After the operation of Add Element(s) to Bank from Container operations, the objects of both the element and its group is retrieved into the Developer Repository as shown below:

(28)

(29)

Note: If the operation of Add Element(s) to Bank is performed directly from

Version Control tab and not from container operations, the object of only that particular element is retrieved into the repository (that is, the objects of the complete group of an element is not retrieved into the Developer Repository).

Check Out

The objects that are in “Check out” status are locked and a symbol appears on the tool bar depicting the same against that particular object. In addition to this, the container operations are not enabled for an object that does not have children on which “Check out” operation is performed.

Undo Check Out

The “Undo Check Out” operation of a versionable object is possible only for a locked object. This means, the operation of Undo Check Out is possible only on an object which is checked out earlier. The following screenshots show a scenario where in an object (by names SERCH) that is already checked out is reverted back with the help of “Undo Check Out” operation.

(30)

Check In

The “Check in” of a versionable object sends the selected object into the Bank. The following screenshots show a scenario where a report “LCKLMT” is checked in.

(31)

Get Latest Revision

This operation of “Get Latest Revision” on a versionable object retrieves the latest revision of a particular object from the VC Bank as follows:

Getting the Latest Revision from the Version Control Bank

using Container Operation

Before performing the Get Latest Revision using Container operation, ensure that the temporary working directory is in sync with the Version Control Bank .The following screenshot clearly depicts how the temporary working directory has to be made in sync with the Version Control Bank for Sub-Version. Perform the following:

1. Right-click on the temporary working directory. 2. Use the option SVNUpdate.

(32)

Setting an Environment with VC Bank Remote Machine

You can set up the VCS environment so that the working folder is placed in one machine and its VC Bank being located in a remote machine by appropriately mapping the LINC.ini parameters. The following example will demonstrate setting up of such environment.

Providing Authentication in the SVN Server

After installing the source version control server (considering SVN here) on the remote machine/host system where the VC bank is present, following are few changes that need to be done in the repository folder where the Bank is created.

(33)

 Inside the folder “conf”, the property of authz file must be changed to provide read-write permissions as follows at the end of the file:

[/] * = rw

 The other file that needs to be changed in Conf folder is passwd. The user credentials are described here as follows:

username = password

 The last file to be modified is the configuration file “svnserve.conf”. To provide permissions to a particular user, perform the following:

Uncomment the following lines in the General Section anon-access = read

auth-access = write password-db = passwd authz-db = authz

realm = My First Repository

Other Required settings

 To be run in the remote machine in order to perform various VC operations from the client. The Svnserve can be run as a service, so that the user does not need to login to the remote machine. For more information on running

Svnserve as a windows service, refer to section Server Configuration > svnserve, a Custom Server > Invoking the server > svnserve as windows Service in the Subversion documentation.

 Once the server i.e., the remote machine is ready, the client (our local machine) setup is mapped properly by setting the LINC.ini parameters appropriately. The following screenshot gives a clear picture of the same.

(34)

 Once the work folder and the Bank are in sync with each other, the user credentials are asked as a first VC operation from the Bank to the work folder, as shown below:

Note: Ensure that the work folder used in this kind of scenario is newly

created.

 Once the work folder is in sync with the Bank, you can go ahead with the VC operations as usual. In Developer, the login credentials are asked as the first operation on a particular Business Segment. The following screenshot depicts the same scenario.

Setting an Environment with VC Bank Remote Machine for TFS

While connecting the TFS machine from the developer, you can either share a common folder to store your source control file in a single folder or you can have individual folder for every user.

(35)

Create a folder in the server and map this folder to a local path. For example, you can create a folder Test, which is mapped to the local folder, c:\tmp:tfs8.

(36)

After you map the path, you are eligible to use the repository.

After completion, the following message in the version control status window is displayed:

Logged into Version Control Bank as DasMK

The following screenshot provides the details of the Version Control Bank:

Advantages of EAE-MS SCCAPI based VCS

Following are the advantages of using the EAE-MS SCCAPI based VCS.

 Enables you to overcome the limitation of an existing VCS by being available on all the windows OSs.

 Allows you to connect to freely available source control systems such as, SVN, CVS, SURE etc.

 Allows you to continue to have both existing VCS and EAE-MS SCCAPI based VCS by setting the LINC.ini option appropriately.

Limitations of EAE-MS SCCAPI based VCS

Following are the restrictions of using the EAE-MS SCCAPI based VCS.

 Migration of EAE Developer Repository with EAE-MS SCCAPI based VCS to another EAE Developer Repository needs to be done manually.

(37)

 Cannot perform Check Out of a particular revision of an object.

 Getting a particular revision into the Developer repository needs be done manually using the source control client. The explorer of the source control client can be used to identify a particular revision of any versionable object and load that file in the .mdl format into any developer repository.

 Objects revision information displays only, “controlled” or “Not controlled”.  Version Control Explorer is not available within Developer, but the source

control tool’s explorer can be used to perform operations instead.  Get By Label operation is not available.

Unable to Suppress the Message from Source Control Provider from TFS

Ignore the below message which is displayed when EAE developer is closed, and click the OK button.

Unable to Cancel the Add Operation from the Source Control Provider

The return value from the Source Control Provider is not the right value when you Cancel an Add operation from the Source Control Provider. Therefore, do not cancel an Add operation from the Source Control Provider.

Features not Available in EAE-MS SCCAPI based VCS

EAE-MS SCCAPI based VCS have been implemented using the existing interfaces that is provided by the Microsoft SCCAPI. It is found that the SCCAPI interfaces for some of the functionalities provided by UREP based VCS are not provided by Microsoft SCCAPI and hence the following operations are unavailable in EAE-MS SCCAPI based VCS:

1. Labelling 2. Branching

EAE-MS SCCAPI based VCS have been implemented to provide an option to the customer to choose the Version Control Systems. Versioning information has been controlled by the respective Version Control Systems and the way various Version Control Systems define and maintain varies from one VCS to another VCS. So, the Developer Version Control Explorer is not available in EAE-MS SCCAPI based VCS.

(38)

Summary

After completing this section you can:  Understand what a ‘versionable object’ is.

 Add, check out, check in, or get a copy of an object in the Version Bank.  Use Container Operations to add, check out, check in, or get a copy of an

object and all its versionable children.

 Rollback changes to an object in the Version Bank.

 Delete, undo delete, or purge an object in the Version Bank.  Assign labels to branches and to versions.

 Add and maintain branch and version labels for a Model.  View Version Control information for an object.