EAE-MS SCCAPI based Version Control System

Transcription

1 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 Revision A

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 Revision A

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) Revision A

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 VCProjectName VCProviderDLLName VCAuxillaryPath VCLocalTempPath 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: C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE Revision A

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 VCProjectName VCProviderDLLName VCAuxillaryPath VCLocalTempPath 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. Note: If this command is not available or disabled, the object you have selected is either not versionable or has not yet been Added or Checked In to the Version Bank Revision A

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. Note: If this command is not available or disabled, the object you have selected 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 appropriately Revision A

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 appropriately Revision A

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 appropriately Revision A

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 updated properly Revision A

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: Revision A

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. 2. Select the Check In command from the Version Control menu Revision A

12 Note: If this command is not available or disabled, the object you have selected 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 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 Revision A

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 Revision A

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: Revision A

15 Steps to Import a Revision from the Exported Data into the Developer Repository 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 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: Revision A

16 Revision A

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. 2. Run the Register.bat file (Preferably run as administrator). 3. Launch the History Explorer by double-clicking Explore3x.exe (Preferably run as administrator). 4. Provide the contents.xml file that is available in the UREP exported data as an input 5. Select the revision and click on View Revision A

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 Revision A

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 Name of the Project which you will be Revision A

20 Option Value Description creating in the source control tool. VCProvider DLLName VCAuxillary Path VCLocalTe mppath String < 256 chars String < 256 chars 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. 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)) 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 Option Value Description EAEMSSCCAPI VC VCProjectNam e VCProviderDLL Name N/Y String < 256 chars String < 256 chars Indicates whether to use existing VCS or EAE-MS SCCAPI VCS. For example, EAEMSSCCAPIVC = Y VC project Name. For example, VCProjectName=projName Name of the project, which you create in the source control tool. Name of the source control client DLL with an absolute path that provides an interfaces to carry Revision A

21 Option Value Description out the VC operations. For example, VCProviderDLLName= C:\Program Files\IBM\RationalSDLC1\ClearCas e\bin\ccscc.dll. VCAuxillaryPat h VCLocalTempP ath EAEMSSCCAPI VC String < 256 chars String < 256 chars N/Y For ClearCase, this variable has no effect. This variable can point to any string VCAuxillaryPath=demo Path points to local work directory. VCLocalTempPath = C:\TEMP\VC 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: Option Value Description EAEMSSCCAPIVC VCProjectName N/Y String < 256 chars Indicates whether to use existing VCS or EAE-MS SCCAPI VCS. For example, EAEMSSCCAPIVC = Y VC project Name. For example, Revision A

22 Option Value Description VCProjectName=projName Name of the project which you will create in the source control tool. VCProviderDLLNa me VCAuxillaryPath VCLocalTempPat h String < 256 chars String < 256 chars 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. Version Control Bank path. For example, VCAuxillaryPath = VCAuxillaryPath = 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 Revision A

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: Revision A

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 Revision A

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. Open the Repo-Browser and do a checkout from the Bank as shown below Revision A

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. Following is an example of eaesync.bat file with userid and password Revision A

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: Revision A

28 Revision A

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 Revision A

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 Revision A

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 Revision A

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 Revision A

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 Revision A

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. The following screenshot provides the details of the TFS Revision A

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:tfs Revision A

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 Revision A

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 Revision A

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 Revision A