|
|
This section uses a sample configuration to show how to use the clearexport_ssafe and clearimport utilities to migrate a set of source files from the SourceSafe configuration management tool to ClearCase control. This section describes the sample SourceSafe configuration, shows how to convert it to a ClearCase configuration, and examines how the conversion process treats various SourceSafe features.
This example assumes that you have created a VOB named \payroll to hold the imported data.
The sample payroll configuration contains source files used to build a payroll application.
Figure 5 Sample SourceSafe Payroll Configuration
Figure 5 shows the configuration hierarchy in SourceSafe, which consists of these projects:
$/payroll project
/progs subproject for storing C programs
/bugfix subproject where developers store source files while fixing bugs
/queries subproject for storing SQL database access files
The payroll configuration contains the following objects: shares, branches, labels, and pins. clearexport_ssafe recognizes and handles some of them during the export phase of the conversion process.
In SourceSafe, shares are similar to hard links. In the example, the $/payroll/bugfix/add.sql and $/payroll/queries/add.sql files are SourceSafe shares. In SourceSafe, any changes that you make to one of these shares appears in the other file.
In SourceSafe, you must create a share before you can create a branch. The $payroll/progs/mod_empl.c and $payroll/bugfix/mod_empl.c files are shared for versions 1 and 2. At version 3, the $payroll/bugfix/mod_empl.c file forms its own branch.
Labels identify a particular version or a project. The Payroll configuration uses the REL1 label to identify the versions of source files used to build the first release of the Payroll application.
By default, SourceSafe uses the latest version of files. Pins allow you to direct SourceSafe to use a version other than the latest. In the Payroll configuration, version three of $payroll/bugfix/mod_empl.c is pinned.
Before you start the conversion process, make sure that certain environment variables and your SourceSafe current project are set correctly.
Verify that the PATH environment variable includes the location of the SourceSafe executable file, ss.exe in SourceSafe Version 5.0, and the ssafeget.bat batch file. For example, if ss.exe is in C:\ss5.0\win32, and ssafeget.bat is in C:\atria\bin, set the PATH environment variable, as follows:
set path=c:\ss5.0\win32;c:\atria\bin;%PATH%
Set the TMP environment variable to a location where clearimport can safely store temporary files. For example:
The clearexport_ssafe utility exports data for files and directories in your SourceSafe current project. Before running clearexport_ssafe, verify that your SourceSafe current project is set so that clearexport_ssafe exports the desired files and directories. For example:
ss cp
Current Project is $/payroll/bugfix
ss cp ..
Current Project is $/payroll
ss dir
$/payroll
$bugfix
$progs
$queries
3 item(s)
The clearexport_ssafe utility reads the files and subprojects in your SourceSafe current project and generates a data file, which clearimport uses to create equivalent ClearCase elements. By default, clearexport_ssafe names the data file cvt_data and stores it in your current working directory. You can specify a different name and storage location for the data file by using the -o option.
By default clearexport_ssafe exports the files and subprojects in the SourceSafe current project, but it does not export any files contained in subprojects. For example, with the SourceSafe current project set to $/payroll, clearexport_ssafe exports subprojects /progs, /bugfix, and /queries but does not export any of the files in those subprojects. To export all files in all subprojects, specify the -r option.
In the following example, the SourceSafe current project is $/payroll. Because the command line specifies the -r option, clearexport_ssafe exports all files in the /progs, /bugfix, and /queries subprojects. The -o option directs clearexport_ssafe to store the output in a data file named paycvt in the c:\datafiles directory.
ss cd
Current project is $/payroll
clearexport_ssafe -r -o c:\datafiles\paycvt
VOB directory element ".".
VOB directory element "bugfix".
Converting element "bugfix\add.sql" ...
Extracting element history ...
....
Completed.
Converting element ...
Creating element ...
Element "bugfix/add.sql" completed.
Converting element "bugfix\mod_empl.c;3" ...
Extracting element history ...
...
Completed.
Converting element ...
Creating element ...
Element "bugfix/mod_empl.c" completed.
VOB directory element "progs".
Converting element "progs\mod_empl.c" ...
Extracting element history ...
...
Completed.
Converting element ...
Creating element ...
Element "progs/mod_empl.c" completed.
Converting element "progs\new_empl.c" ...
Extracting element history ...
...
Completed.
Converting element ...
Creating element ...
Element "progs/new_empl.c" completed.
VOB directory element "queries".
Converting element "queries\add.sql" ...
Extracting element history ...
...
Completed.
Converting element ...
Element "queries/add.sql" completed.
Converting element "queries\update.sql" ...
Extracting element history ...
...
Completed.
Converting element ...
Creating element ...
Element "queries/update.sql" completed.
Creating script file c:\datafiles\paycvt ...
Use any view. clearimport ignores the config spec.NOTE: You cannot run clearimport in a UCM view.
Set your working directory to the VOB directory in which you plan to import the configuration. You can run clearimport from a location other than the VOB directory by specifying the VOB directory with the -d option. You must specify the pathname of the data file created by clearexport_ssafe.
clearimport c:\datafiles\paycvt
Validating label types.
Validating directories and symbolic links.
Validating elements.
Creating element ".\bugfix/add.sql".
version "1"
version "2"
version "3"
version "4"
Creating element ".\bugfix/mod_empl.c".
version "1"
version "2"
version "3"
version "4"
Creating element ".\progs/mod_empl.c".
version "1"
version "2"
Creating element ".\progs/new_empl.c".
version "1"
version "2"
version "3"
Creating element ".\queries/add.sql".
version "1"
version "2"
version "3"
version "4"
Creating element ".\queries/update.sql".
version "1"
version "2"
version "3"
version "4"
Closing directories.
After clearimport finishes populating the VOB, examine the version trees of the new ClearCase elements to verify that clearexport_ssafe and clearimport converted the SourceSafe configuration as you expected. In Windows Explorer, open the VOB folder and select an element. Then, click File > ClearCase > Version Tree. Figure 6 shows the version tree for the \bugfix\mod_empl.c element.
Figure 6 ClearCase Version Tree of \bugfix\mod_empl.c Element
As it does with all elements, ClearCase adds a version 0 as a placeholder at the start of the version tree.
The conversion process maps SourceSafe labels directly to ClearCase labels, so version 2 of mod_empl.c has the REL1 label as it does in the SourceSafe configuration.
In the SourceSafe Payroll configuration, at version 3, the $payroll/bugfix/mod_empl.c file forms its own branch. clearexport_ssafe does not convert SourceSafe branches to ClearCase branches. Instead, clearexport_ssafe creates separate elements. In this case, it creates versions 1 and 2 of the mod_empl.c element in the \progs directory, and versions 1 through 4 of mod_empl.c in the \bugfix directory.
ClearCase does not have a feature equivalent to a SourceSafe pin. Sometimes, pins perform the same function as labels; therefore, the conversion process maps pins to labels. In the SourceSafe Payroll configuration, version 3 of mod_empl.c is pinned. The conversion process applies a label with the name PINNED.
ClearCase does not have a feature equivalent to a SourceSafe share. clearexport_ssafe does not preserve shares as hard links during conversion. Instead, shares become separate elements.
|
|
Feedback on the documentation in this site? We welcome any comments!
Copyright © 2001 by Rational Software Corporation. All rights reserved. |
