ClearCase to SVN migration

Question

Well I have an issue with SVN importer tool for migrating one of the ClearCase VOB which has a huge history ..we thought of doing this by picking up like 10 -15 baseline versions of the code and import it to SVN. So for doing that I think the user has to give me the specific versions one by one . So now he is asking me how to point a specific version in clearcase and export it ?? .The idea here is to give me the code as tar ball ...so that I can explode it on my desktop and import it then to SVN. ....!!!! I Don know how to import / layer in all this baselines in SVN.......Is that something similar to SVN. Can you please help me with this.

Answer 1

I have not used it, but I have heard that SVNImporter will import your ClearCase VOBS including the history.

It sounds like what your user is really asking for is to export a few versions at a time from CC to basically 'colapse' the existing history. Say for example that you have a large VOB with thousands of revisions and hundreds of labels, and you want to have only the last 5 major releases as your history in the new subversion repository. You could export the earliest desired version from CC, import into SVN and create a working copy. Then you would export some later version from CC and copy into your working copy and do an update. Lather, rinse, repeat until you get to LATEST from CC.

The version you would get from CC is controlled by the views config spec. To get only files associated with a particular label (hopefully they have labels...) you change the config spec to:

element /vob/MyPath/… DESIRED_LABEL

To get the versions associate with a label AND the current version of anything not associated with that label you use:

element /vob/MyPath/… DESIRED_LABEL
element /vobs/MyPath/… /main/LATEST

For more information see the IBM/Rational config_spec documentation.

Answer 2

Note: if by "baseline" you are referring to "UCM Baseline", this becomes simpler for a given component (tree of files within a Vob).

Create a UCM project with a single Integration Stream and a dynamic view on it, then:

ct lsbl -s component:myComponentToExport@\myPVob

will give you the list of baselines to export.

ct rebase -bas myIntStream@\myPVob aBaseline

within the dynamic view will set the view as a source for your export.
(Repeat for each baselines, for the oldest you want to import to the most recent)

---

But if you are with data labeled with base-ClearCase (and not UCM), be aware of this issue:

a base-ClearCase label can be put on any file. Rule like the one suggested by Gary

element /vob/MyPath/... DESIRED_LABEL

can very well end-up selecting 0 files, simply because the label 'DESIRED_LABEL' has not been put on the root-directory 'MyPath'!

---

Plus there is no notion of "timeline" revision (like the revision in Subversion).
If the label prove too unreliable (because not put on all the files), a solution could be to combine the date of the label with a time-based rule.

element /vob/MyPath/... DESIRED_LABEL
element /vob/MyPath/... .../myBranch/LATEST -time (date_Of_The_Label_Put)

'date_Of_The_Label_Put' being the date of the application of the label on at least one element.
If some elements had not been labeled, they would still be selected at the correct version, i.e. the version at the time of the label being applied partially on a set of files.

Answer 3

I did some clearcase migration by myself: here are my thoughts:

1. Do NOT use the importer suggested by Gary Ray, as it is not very mature. It lacks a lot of features you want to have, for example directory versioning, correct tags with old filenames, history of deleted files, etc.. This importer is only for small scale migrations where your really need the contents of your files and can loose the overall structural changes

2. create a list of tags you want to export

3. write a script to generate the clearcase config-spec for each tag in your tag list

4. alternative: create a list of config-specs for each tag, if you cannot succeed in step 3

5. tar and zip your clearcase view and copy collect it on your SVN machine

6. extract each zip to a folder

7. use svn_load_dirs.pl for importing into SVN, you may also want to create a tag in SVN

8. goto 6 with next tag

Note, that this will also work with multiple projects. However if you have shared modules(one of weak points in SVN) you will need a specific repo-structure and import into SVN can be more complex(maybe use svn:externals). You really should automate the process, as most of the time you will import more than once, because your config-specs are missing files, your SVN structure will change, etc. So script the solution and run everything automatically, which will be much more flexible until all migration is over. You may also need to review the migration result.