Contents - OpenMake Software

MKS-SVN Migration Data Mapping Using
Polarion SVN importer
Contents
An overview of the MKS to SVN
Migration process
By Quinn Bailey, DevOps Consultant,
OpenMake Software
Summary………………...1
Overview…..2
Process……………..….2
Configuration Parameters…3
Limitations ……..3
Conclusion …….4
Summary
When migrating from MKS to Subversion it is important to understand the data mapping that is
possible between these two different version control systems. When doing this sort of migration, a
“full version history” conversion is often requested. A more accurate description of what actually
can occur is a transformation of the MKS project data into the SVN repository format. This data
transformation migrates the MKS projects and file revisions themselves, as well as associated
metadata. This document is intended to detail the nature of the data transformation that the SVN
importer software provides for MKS and the parameters that most directly affect the conversion.
process.
1
Overview
To understand what SVN importer provides, it helps to understand the basic technical details of
the tool’s conversion process. SVN importer works by using a series of MKS command line tools
to gather MKS project metadata, which it then uses to create an internal model of the project
history. This model is then used to call out to other MKS commands to extract the appropriate
file revision data from MKS. Finally, the MKS model is transformed into an SVN model, which
the tool uses to convert the extracted MKS data into a SVN repository “dump” file.
Process
The si commands that the conversion process is primarily dependent on for constructing its
MKS model are the projectinfo, viewprojecthistory and rlog commands. The
most critical historical metadata is retrieved from projectinfo and
viewprojecthistory. The actual file revision content is retrieved by using
viewrevision.





projectinfo is used to get the root checkpoint associated with each development
path, so the origin revisions of SVN branches are accurately represented in the model.
viewprojecthistory is then used to record each and every MKS checkpoint into
the model.
projectinfo and viewprojecthistory both rely on the MKS project (.pj)
file to run.
rlog is then used to gather data for every file revision in the project and place it into
the correct location in the SVN model, i.e. onto the correct branch, in the correct order.
viewrevision can then be called for each file revision.
The tool then knows how to construct a SVN repository dump file from this data that can
contain all file revisions on the main and alternate development paths. If desired, the tool does
allow for this data to be reduced to contain the trunk (root path) only, or to contain only the
latest revision from the trunk and branches (alternate development paths).
2
Configuration Parameters
The configuration parameters for the MKS to SVN importer are mostly straightforward. The
single most important option is mks.tag.option, as this determines what will be brought
into the “tags” folder of the converted SVN repository. You can choose to convert:




no tags at all
tags by checkpoint number
tags by label
tags specified by a combination of both checkpoint number and label.
The options for converting both checkpoint numbers and labels allow either the number or the
label to take precedence, or the number and label can both be used. Other options have to do
with so-called orphaned revisions, revisions that are not on the standard path or on any defined
alternate development path. If orphan revisions are found, the configuration options for SVN
importer provide the capability to deal with these by creating so called orphan branches in SVN
to hold these file revisions that have no proper home in SVN. Options are available to allow
the creation of orphan branches and if selected, provide a prefix for these branches.
Limitations
If there is one limitation of the tool, it is that the tool can suffer from performance issues, in
particular with very large projects, which is defined as projects containing tens of thousands of
files with numerous revisions and branches. Because the conversion relies on large amounts of
network and file I/O to do its work, no conversion is particularly speedy, but very large
conversions can take days to complete. In one extraordinary case, the conversion time
extended to roughly a week. Also of concern with the performance are the memory
requirements. Again, more typical projects can expect to be easily converted with average
hardware (2-4 GB RAM), but very large projects may require significantly more (8-16 GB or
more RAM). This is because when the tool transforms the source repository model into the
SVN model, it does so in memory. While the models don’t include the actual file revision
contents, which are stored on disk, for very large projects even just the structure and metadata
of the project to be converted can become extremely large and conversions without sufficient
RAM allocated will crash.
3
Conclusion
While performance can hinder the speed of the conversions, in general the quality of the
conversions produced with this tool is very high. Virtually all metadata that has an analog in
SVN is migrated into SVN from the source repository. This data includes:





accurate dates/times of historical revisions,
user names
check-in comments
branch histories including “branch roots” (revisions from which branches originated)
tags (i.e. checkpoints and labels from MKS).
In some cases, user requirements may necessitate the customization of the tool to include
other data not included with the default conversion, often by adding this data to the commit
comments or SVN file properties.
4

Download Report