Migrate2SVN migrates the complete ClearCase version history of each file, including checkin comments, authorship and checkin timestamps.
Tags and branches can also be migrated. However, this will require additional configuration to make sure the correct data set is transferred. Please see the Migrate2SVN User Guide for details.
If you are moving from ClearCase to Git, you can use Migrate2SVN to migrate your data from ClearCase to Subversion first, followed by a migration to Git using Git's Subversion integration (git svn).
Please see the Migrate2SVN User Guide for details.
However, please note that tags and branches will not be migrated to Git from a Subversion repository created with Migrate2SVN. See section "Why are tags and branches not migrated to Git" for details.
Migrate2SVN has been tested with ClearCase 7. However, as only standard calls to cleartool are used, it is expected to work with a wide range of ClearCase releases.
Migrate2SVN has been tested with Subversion 1.5 and 1.6. Since the Subversion dump file format is intended to be compatible with a wide range of Subversion releases, future versions of Subversion should be able to read the dump file generated by Migrate2SVN.
Yes, Migrate2SVN can be used with ClearCase UCM data. UCM branches and labels are represented as normal branches and labels, which can be migrated with the Migrate2SVN tool.
Migrate2SVN uses a cache directory to hold copies of the element versions to be migrated. If the config option check_zero_size_cache_file is switched on, Migrate2SVN will always refetch empty files. Under certain error conditions, ClearCase may fail and leave an empty file behind when fetching element versions. Always refetching files is a precaution to catch this error condition so that a failure from a previous run does not impact on subsequent runs.
You can switch this behaviour off by setting check_zero_size_cache_file to false. However, please make sure you check the cache for inconsistencies if you encounter ClearCase errors.
Migrate2SVN fetches ClearCase element versions into a staging area (cache), which is reused on subsequent runs of the tool. Once a migration has been completed, you may want to reclaim the disc space used by cleaning out the cache directory.
The location of the cache directory location is specified in the Migrate2SVN config file with the cache_dir option. It is safe to delete this directory at any point, provided Migrate2SVN is not running at the time.
Git's Subversion integration (git-svn) allows you to migrate tags and branches from a Subversion repository into Git. However, as the Git branching model is effectively represented by a pointer to a particular revision in the Git repository, git-svn needs to be able to trace back any branches or tags in the Subversion repository to a single revision on the Subversion trunk.
When migrating from a ClearCase repository, where tags and branches are made up of a combination of file revisions, tags and branches need to be built up incrementally, and whilst individual file revisions can be traced back to revisions on the trunk, there is no overall revision on the trunk that represents a tag or a branch in its entirety. As a result, git-svn will not be able to perform this mapping and tags and branches will not be visible within Git.
Please note that this limitation is due to the nature of a migration from a file-based configuration management system into a repository-wide-revision based system and cannot be overcome without introducing other, much more significant, limitations.
The following scenario is the most likely explanation of this behaviour.
This is due to the fact that the element only has a revision on main, not on the branch.
In addition, if the element is subsequently deleted from the other branch (although it may not be visible on the main branch in ClearCase) it may still appear in the Subversion repository (on the branches/main folder).
Again, this is due to the fact that ClearCase removes the link to the element on the branch, but the element will still have a revision on main.
You can check this by navigating to the file in question within ClearCase checking that version is on main, not on your branch
Migrate2SVN will not migrate folders from ClearCase than have never contained files.
It is possible to see empty folders in the SVN repository after migration; however this is likely to be because a file was created and also deleted from the folder
For an explanation of the Evil Twin files in ClearCase, please see http://www-01.ibm.com/support/docview.wss?rs=984&uid=swg21125072
When Evil Twin files exist in ClearCase, the behaviour of Migrate2SVN will be as follows
The file contents in the SVN repository will be the same as the file contents for the 'original' file at the latest revision of the Evil Twin.
The file contents will be as expected (i.e the same as the file contents at the latest revision of the Evil Twin).
Migrate2SVN uses cleartool to interact with ClearCase, and it generates a dump file to be loaded into Subversion.
You can run Migrate2SVN on any machine that has access to the ClearCase VOB through a suitable view. There is no need for Subversion access on the host that Migrate2SVN is executed on.
Once the Subversion dump file has been generated, it can be transferred to the Subversion server to be loaded with svnadmin load.
Although Migrate2SVN will migrate the 'user' names (for element updates etc...) from ClearCase to Subversion, it is not necessary for those users to exist in Subversion. However if you need those users to have access to the migrated Subversion repository, you will need to add them.
Migrate2SVN migration is a consulting service provided by Clearvision CM. Different consulting packages are available ranging from fully serviced migration and DIY migration following initial training and setup.
The License is a fixed term based license, with a number of options available. Please see the Migrate2SVN section on our website or contact Clearvision Sales for more details.
Due to the main differences between ClearCase and Subversion, there are certain circumstances where development can continue in the new SVN repository.
The main points to note are as follows:
Most importantly you should not merge any branches into their parents, i.e.
The likelyhood is that for your ClearCase /main/subBranch1/myPersonalBranch/ you will have a view that looks similar to:
element * CHECKEDOUT element * .../myPersonalBranch/LATEST element * .../subBranch1/LATEST -mkbranch myPersonalBranch element * /main/LATEST -mkbranch subBranch1
In order to replicate this in your SVN repository, you would do the following:
 |
Do not be surprised if you see some files in this new branch that you could not see in your ClearCase view.
For your own piece of mind, after performing the SVN steps above, you can run a tree based diff on your new SVN branch and your config spec to locate these files |
This is due to the fact that in CC the file line endings are not converted to the local system type.
For example if a user on windows checked in a file (in CC) and then a user on Linux checked out that file, the line endings are preserved and the Linux user would see the extra \r character.
In Subversion (through the use of the svn:eol-style property) the line endings of the files are automatically altered to match your OS.
 | The types of files that have their line endings modified between systems are dependant on what autoprops you set for the migration |
.
When comparing file content, be sure to ignore white space. If keeping the eol is imperative, consult the Migrate2SVN Documentation on how to adjust the svn auto properties.