|
⇤ ← Revision 1 as of 2008-05-20 21:54:48
Size: 2812
Comment:
|
Size: 3944
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| = Conversion of ClearCase repositories to Mercurial = |
|
| Line 2: | Line 4: |
| Certainly, some or all of the above mentioned names may be registered trademarks. | |
| Line 4: | Line 7: |
| Like SCCS, RCS and CVS, ClearCase handels revisions for each file individually, so that each file has its own revision numbers, assigned labels etc. | |
| Line 6: | Line 8: |
| When importing a ClearCase VOB, you should decide whether you want to start at a certain point in time or from the very beginning. Depending on this, you can setup a time based ClearCase view specification so that you see either a nearly empty or already filled repository. | Like SCCS, RCS and CVS, standard ClearCase handles revisions for each file individually, so that each file has its own revision numbers, assigned labels etc. Usually each file and directory has a mainline, numbered /main/1 to /main/N and can additionally have several branches starting at defined revisions. Furthermore each revision can have multiple labels assigned. |
| Line 8: | Line 10: |
| If you decide not to start at the beginning, then copy sll files visible with the viewspecification of your choice into a new directory structure and run the usual "hg init; hg add; hg commit" on it to create a new Mercurial repository. | Files and Directories are presented to a user in so called VOBs through the ClearCase filesystem. What the user sees, depends on a so called view specification where he can fine tune which label, revision number or point in time should be used for an entire VOB, subdirectory with all decendants, or a single file or directory. So each user can see different data under the same directory path. |
| Line 10: | Line 12: |
| Later, you can use the ClearCase find command in order to detect most of the changes that have been applied later. | When importing a ClearCase VOB, it has to be decided whether to start at a certain point with all elements present at that time or from the very beginning. Depending on this, one can setup a time based ClearCase view specification so that either a nearly empty or already filled repository is visible. When not staring at the beginning, then copy sll files visible with an active view using the viewspecification must be copied into a new directory structure and put into a new Mercurial repository using the usual "hg init; hg add; hg commit". Later, it is possible to use the ClearCase "find" command in order to detect most of the changes that have been applied later. |
| Line 13: | Line 19: |
| {{{ | |
| Line 14: | Line 21: |
| }}} | |
| Line 15: | Line 23: |
| will list any new elements that have been created later than a certain date (usually you will use the date of your latest Mercurial repository update here). elements here means, new file revisions and new directory revisions as ClearCase does versioning for directories as well. | will list any new elements that have been created later than a certain date (usually the date of the latest Mercurial repository update should be used here). "elements" here means "new file revisions" and "new directory revisions" as ClearCase does versioning for directories as well. |
| Line 17: | Line 25: |
| For new files, typically versions with extensions /main/1 will hold the first usable content while /main/0 versions can mostly be ignored. | For new files, typically versions with extensions "/main/1" will hold the first usable content while "/main/0" versions can mostly be ignored. |
| Line 19: | Line 27: |
| Note that the list of files is not sorted in any way yet, so you must order them yourself, e.g. by using a 'stat' on the full path specifications to obtain the modification (and here also creation) date. | Note that the list of files returned by the command above is not sorted in any way yet, so it must be ordered first, e.g. by using a 'stat' on the full path specifications to obtain the modification (and here also creation) date. Alternatively 'cleartool describeÄ can be used to obtain the date. |
| Line 21: | Line 29: |
| Once the elements are sorted by time, you can start to process them and for each element | Once the elements are sorted by time, the can be processed and for each element |
| Line 23: | Line 31: |
| * create the necessary path in your Mercurial repository, if needed * copy the new file version into the repository * use 'hg add' where needed * commit the new file with the comment, date string and author derived from ClearCase |
* the necessary directory path in the Mercurial repository must be created, if needed * the new file version must be copied into the repository * the 'hg add' must be used where necessary * the new file must be comitted with the comment, date string and author derived from ClearCase |
| Line 28: | Line 36: |
| The comment and the user can be obtained from ClearCase by using commands like 'cleartool describe -fmt '%c'' or '... %u' respectively. | The comment and the user can be obtained from ClearCase by using commands like {{{cleartool describe -fmt '%c'}}} or {{{... '%u'}}} respectively. |
| Line 32: | Line 40: |
| * You will not be able to detect symbolic links this way, as symbolic links are not own elements, but just records in the directories * You will not be able to detect file removals or renames, or directory removals or renames |
* It is not easily possible to detect symbolic links this way, as symbolic links are not own elements, but just records in the directories * It is not easily possible to detect file removals or renames, or directory removals or renames |
| Line 35: | Line 43: |
| For these, you would have to look at the directory elements which you got through the find command earlier in detail. Currently I am not aware of a method to find out what exactly happened between two directory revisions, as several files or subdirectories could have been removed or renamed in between. | For these, the directory elements which you are returned by the find command earlier must be analyzed in detail, which might be difficult, because several files or subdirectories could have been removed or renamed in between. After an incremental conversion is done, it is a good idea to check using a recursive find call, and an recursive md5sum, whether the new version of the Mercurial repository is identical to the ClearCase repository. |
Conversion of ClearCase repositories to Mercurial
IBM Rational ClearCase is a commercial revision control software, for details refer to http://en.wikipedia.org/wiki/ClearCase. Certainly, some or all of the above mentioned names may be registered trademarks.
This article describes how a conversion of a ClearCase VOB to Mercurial could theoretically work.
Like SCCS, RCS and CVS, standard ClearCase handles revisions for each file individually, so that each file has its own revision numbers, assigned labels etc. Usually each file and directory has a mainline, numbered /main/1 to /main/N and can additionally have several branches starting at defined revisions. Furthermore each revision can have multiple labels assigned.
Files and Directories are presented to a user in so called VOBs through the ClearCase filesystem. What the user sees, depends on a so called view specification where he can fine tune which label, revision number or point in time should be used for an entire VOB, subdirectory with all decendants, or a single file or directory. So each user can see different data under the same directory path.
When importing a ClearCase VOB, it has to be decided whether to start at a certain point with all elements present at that time or from the very beginning. Depending on this, one can setup a time based ClearCase view specification so that either a nearly empty or already filled repository is visible.
When not staring at the beginning, then copy sll files visible with an active view using the viewspecification must be copied into a new directory structure and put into a new Mercurial repository using the usual "hg init; hg add; hg commit".
Later, it is possible to use the ClearCase "find" command in order to detect most of the changes that have been applied later. For example
cleartool find /yourpath -version \"brtype(main) && created_since(yourdate)\" -exec \"echo \\\$CLEARCASE_XPN\"
will list any new elements that have been created later than a certain date (usually the date of the latest Mercurial repository update should be used here). "elements" here means "new file revisions" and "new directory revisions" as ClearCase does versioning for directories as well.
For new files, typically versions with extensions "/main/1" will hold the first usable content while "/main/0" versions can mostly be ignored.
Note that the list of files returned by the command above is not sorted in any way yet, so it must be ordered first, e.g. by using a 'stat' on the full path specifications to obtain the modification (and here also creation) date. Alternatively 'cleartool describeÄ can be used to obtain the date.
Once the elements are sorted by time, the can be processed and for each element
- the necessary directory path in the Mercurial repository must be created, if needed
- the new file version must be copied into the repository
- the 'hg add' must be used where necessary
the new file must be comitted with the comment, date string and author derived from ClearCase
The comment and the user can be obtained from ClearCase by using commands like cleartool describe -fmt '%c' or ... '%u' respectively.
There are certain problems left:
- It is not easily possible to detect symbolic links this way, as symbolic links are not own elements, but just records in the directories
- It is not easily possible to detect file removals or renames, or directory removals or renames
For these, the directory elements which you are returned by the find command earlier must be analyzed in detail, which might be difficult, because several files or subdirectories could have been removed or renamed in between.
After an incremental conversion is done, it is a good idea to check using a recursive find call, and an recursive md5sum, whether the new version of the Mercurial repository is identical to the ClearCase repository.