Reputation: 12477
Our project currently uses ClearCase for source control. This limits our development, so we are going to move to Git. Unfortunately, for contract reasons, we have to continue to maintain our code in ClearCase. We are going to be using Git for day-to-day development, but we will have to check in our code to Clearcase each release. What is the best way to do this?
Example
Let's say the Git code is v7.0, while in Clearcase it is still v6.0. Given the Git v7.0 codebase, I'd like ClearCase to somehow be able to figure out automagically what files have changed since v6.0. Is there a way to easily insert all the Git code changes from v6.0 to v7.0 into ClearCase as one big v7.0 commit within ClearCase?
Thanks!
Upvotes: 2
Views: 206
Reputation: 1329092
The easiest way is to use the ClearCase command clearfsimport
: it will import any folder (Like the root folder of a git working tree) into your ClearCase (snapshot or dynamic) view.
It will detect the modified, removed or added files.
Once the import is done, you can put a label on all the current versions, or if you are using UCM a baseline.
Remember that ClearCase works file by file and has no notion of a repository wide commit or revision. Hence the label or baseline after the import.
See more about the differences between ClearCase and Git in "What are the basic clearcase concepts every developer should know?".
Does it matter if the Git code does not have the appropriate .copyarea.db files when we run the clearfsimport command?
See "Should I ignore .copyarea.db
file when committing a new file to RTC source control?"
It doesn't matter, as long as the clearfsimport
doesn't attempt to import it (you could remove it from the git working tree).
See also "Clearfsimport imports .copyarea.db
files as file elements"
However, it also means CCRC web view, which means clearfsimport
is probably not available on the client post: you might want to do that import from a dedicated post with a full ClearCase client installed (instead of just CCRC).
Upvotes: 3