Question

I need only the source tree and its history. I don’t care for the requirements/issues stuff for now. I played a bit with the command line to figure out if I could get a list of change packages for the trunk and some of the dev paths. I thought it should be possible to extract a diff for every change package and use that to replay all the changes since the first commit in git. Something like this:

1. get first commit and add it to git
2. get next CP
3. get diff for CP
4. apply diff to git working dir
5. add and commit changes to git
6. repeat with (2.) until last CP

You could also replace change package with checkpoint (would be good enough for me).

A simpler way would be to just checkout a CP and add/commit to git. But then you would loose track of add, remove, move and rename operations.

Does anyone know how to get a unified diff from "si diff"? That would already help alot.

Any ideas?

Edit2:
Added an answer that shows how I actually did the migration…

Answer 1

The problem with MKS Integrity is their unique repository in which everything resides:

• requirements,
• test plans,
• test cases,
• features,
• developer tasks,
• deployment requests

Since those data can evolve independently one from another, at their own pace, importing them all in one Git repository would be a bad idea: you can only clone all the content of a Git repo (even if you can limit the depth of that clone).
That means you will get all the documents, even though you are just interested in the code.
An MKS Integrity export would imply to define first many Git repositories to act as submodules.

---

I need only the source tree and its history.

As usual, I would recommend only importing:

• the major labels (for anything older than a year, or whatever period you feel comfortable you won’t need the examine in full because it is so old)
• all the labels (major and minors) for the last years.

And I would not import all in one Git repository unless you are confident that all your sources represents one system developed as a all (and not several “modules” developed independently)

A simpler way would be to just checkout a CP and add/commit to git.

That would be the way to proceed.

But then you would loose track of add, remove, move and rename operations.

No! You would not! Git will infer those operations.
That is the advantage of being a file Content VCS.