1

We are moving our code from CVS to ClearCase in order to consolidate our history in only one vcs system following the guidelines provided here http://www.ibm.com/developerworks/forums/message.jspa?messageID=13728313.

At first glance everything looked fine. All versions of all files appear to have been migrated, all branches and tags from CVS exist in ClearCase.

However not all files have branches created correctly (in my opinion). The example file.bat has the following history (hope the ascii drawing is understandable).

1.1
1.2 --- SOME_TAG
1.3 --- SOME_OTHER_TAG
   |---- BRANCH_1
1.4 --- BRANCH_2
       |- 1.4.2.1
       |- 1.4.2.2

Now, both SOME_TAG and SOME_OTHER_TAG is created and applied correctly in ClearCase. BRANCH_2 is created from CVS version 1.4 with version 0 on the branch having the same creation date/time as the CVS version 1.4. Which is good. Version 1.4.2.1 and 1.4.2.2 is created as version 1 and 2 respectively on BRANCH_2.

The problem is BRANCH_1 which is not created. As a minimum I would have liked to have the branch possibly only with version 0 on it.

I can see from the output of clearexport_cvs that the issue stems from here. The BRANCH_1 tag is not included in the output from clearexport_cvs command, only SOME_OTHER_TAG.

Any good ideas as how to rectify this? I couldn't find any options or switches on the clearexport_cvs command which seemed to help me.

It is important that we keep the original timestamp from CVS in order to be able to get the correct sourcecode for old builds. We used Parabuild so the only reference to CVS we have per build is similar to this "cvs update -P -A -d -D "2012-12-20 13:31:42 GMT" -r BRANCH_1" Kind regards Peter

Peter Kristiansen
  • 31
  • 3

1 Answers1

0

If the clearexport_cvs doesn't work completely, and since there is no way to export only one branch, It is best to try fixing the import incrementally, and do a clearfsimport on a a dedicated ClearCase branch.

That would allow you to "patch" the history import with a few selected revisions from the CVS repo, but this isn't an automated process (unless you script the update of a CVS workspace, a bit like I did for Subversion).

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • I'm not sure that would work in my case. The branch does exist for some other files, i.e. those files which were modified after creating the branch. Assume that some files has a similar structure for BRANCH_1 as the above example shows for BRANCH_2. – Peter Kristiansen Mar 11 '14 at 11:43
  • @PeterKristiansen the `clearfsimport` would import only the delta it detects. As long as you are able to put a label on a given `branch1` state (from where you start `branch2`), you can then do a few import manually. – VonC Mar 11 '14 at 11:57
  • I hear you, but the problem is that there wouldn't be any changes to put on the branch, as there hasn't been made any changes in CVS for the file in question on BRANCH_1. Basically I would just need version 0 on BRANCH_1 for this particular file. Another thing I forgot to mention (will add it now) is that I need to preserve the original timestamp that the file had in CVS. – Peter Kristiansen Mar 11 '14 at 13:45
  • @PeterKristiansen clearfsimport would still take care of that case. But if not, then there isn't much solution than to debug `clearexport_cvs`, I am afraid... – VonC Mar 11 '14 at 13:47
  • I'll try to be more clear with why I believe that clearfsimport wouldn't work. We already have version 1.3 in ClerCase as version 3 on the main branch. I would like to get a BRANCH_1 created from version 3, with at least a version 0 which has the same creation time (and content) as the version 1.3 in CVS. Given I would like to end up with the same content clearfsimport, as it detects deltas, wouldn't catch it. As far as I understand. – Peter Kristiansen Mar 11 '14 at 13:55
  • @PeterKristiansen that will work fine. As long as you have a label in place marking the versions from which you want to start `branch1`, `clearfsimport` *will* create a version 0 with the same content (not sure about the creation date) than version 3. That is what clearfsimport is *meant* to do. (in a view with a config spec made for creating `branch1` for any new versions, and looking by default at the label making the starting point of `branch1`) – VonC Mar 11 '14 at 13:57
  • Oh, then I think I misunderstood clearfsimport. I'll have a look at it tomorrow and get back to you. – Peter Kristiansen Mar 11 '14 at 13:58
  • @PeterKristiansen you would need to use `clearfsimport` in a view with a config spec made for creating `branch1` for any new versions, and looking by default at the label making the starting point of `branch1`. – VonC Mar 11 '14 at 13:58
  • I checked some of the other files, and they don't all have the same label attached in CVS, so I can't create a config spec which picks up the correct files. I'm afraid that's a dead end. Anyone have any ideas if it is possible to get clearexport_cvs to behave properly :)? - But thank you for you great suggestions! – Peter Kristiansen Mar 12 '14 at 07:54
  • @PeterKristiansen as long as you have have a view on LATEST of `branch1`, which represents `CVS 1.3`, you an put a label on *all* visible elements, and use that as a starting point. So I wouldn't qualify it as a dead-end yet. – VonC Mar 12 '14 at 08:31
  • Unfortunately I don't. All versions from CVS is loaded into CC meaning that I have 1.4, and the versions on the subbranch BRANCH_2 as well. I can't get a latest on BRANCH_1 for the file in question, in ClearCase, as it hasn't been created at all. Neither has the version 1.3 been labeled with a label corresponding to BRANCH_1. – Peter Kristiansen Mar 12 '14 at 09:20
  • @PeterKristiansen could you somehow import the 1.3 files from CVS into ClearCase, set a label, and import 1.4 (2 manual imports with `clearfsimport`)? – VonC Mar 12 '14 at 09:23
  • I probably could. But it seems as if it would require a lot of manually fidgeting with doing several imports for several versions for several branches. I'm not sure how many thousand files we have where the history looks different for each of them; some have versions on the different branches and some doesn't. It seems as if it would be a manual migration of the history, and I believe that would take too long and be much to error prone. – Peter Kristiansen Mar 12 '14 at 12:26
  • @PeterKristiansen I usually do those import through a massive copy, and a kdiff3 to make sure I have the right content, before doing a `clearfsimport`. The number of files become then a non-issue. – VonC Mar 12 '14 at 12:40
  • But the number of builds (i.e. different point in time we are interested in) would still be a limiting factor I guess. One has 1352 builds and we have ~40 builds to manage. Mind you the others vary between 10 and a few hundred, but still too many to handle manually, we would have to script our way out of it. Therefore I would much prefer if anyone had any luck with the clearexport_cvs tool :o) – Peter Kristiansen Mar 13 '14 at 07:42
  • @PeterKristiansen I understand. My option is for a few manual import only, not for an exhaustive history import. – VonC Mar 13 '14 at 07:47
  • But definately a good idea. Thank you for your suggestion :o) – Peter Kristiansen Mar 13 '14 at 08:57