I need only the source tree and its history. I don't care for the requirements/issues stuff for now. I played a bit witth 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:
- get first commit and add it to git
- get next CP
- get diff for CP
- apply diff to git working dir
- add and commit changes to git
- repeat with (2.) until last CP
You could also repleace 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...
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.
I cannot post the actual program I wrote, because I did not do it on my own time. However, I can post how I did it. It should be easy to redo it with any scripting language. The tool I wrote migrated only one branch at a time. I would tell it which branch I want (e.g. 1.21.1) and the starting and ending revision in the branch (e.g. 4 and 78 would migrate all revisions starting from 1.21.1.4 up to 1.21.1.78). To have all branches in one repo I would provide the .git directory to use for importing into.
- begin loop from starting revision to ending revision
- CURRENTREV=BRANCH.loopcounter
- create the repo directory
- move the .git dir into the repo directory
- move the .gitignore file into the repo directory
- chdir into the repo directory
- create mks sandbox inside the repo dir via "si createsandbox -P MKS_PROJECT_PATH --yes --projectRevision=CURRENTREV
- fetch revision description via "si viewprojecthistory --rfilter=range:CURRENTREV-CURRENTREV", capture output!
- extract user, date, label(s), comments from previous output
- "git add ."
- pipe extracted info from above into "git commit -qF -" (cannot do -m if you want multiple lines like the checkpoint comment)
- drop sandbox via "si dropsandbox --yes index.pj"
- move .git and .gitignore to a save place (for next iteration)
- delete all remaining files in the sandbox directory
- move to parent dir (..)
- delete sandbox/repo dir
- create final git dir
- move .git and .gitignore into final git dir
- "git reset --hard HEAD"
Done.
MKS uses some kind of ASCII encoding for its string and git usually uses UTF-8 so watch out for problem when importing meta data into git (user names, comments, tags etc.).
For more branches do this:
- in the git directory checkout the revision where the branch should start and create a branch ("git checkout -b NEWBRANCHNAME")
- now move .git and .gitignore to the save place and delete the whole dir
- now do the same thing as above
One more thing: "si" is the MKS command line tool. So you either need to specify its complete path or put its path into the search path.
FWIW, si diff sadly doesn't currently support unified diff. There is a request for change to have it do so, but there haven't yet been too many customers asking for that feature.
DISCLAIMER: I work for PTC (who acquired MKS).
This works for checkpoints...
https://gist.github.com/2369049
Unfortunately, checkpoints are seemingly the only thing that really makes any sense from MKS -> GIT, as a checkpoint is really the closest thing to the "snapshot" which GIT calls a commit.
MKS has so many incompatible concepts (per file version tracking, branches that are nothing like GIT branches, checkpoints, etc. ) which can all evolve independently from one another it is really hard to tell how to migrate a sensible history into GIT. There are probably many ways to do it and none of them more "correct" than the next.
That said, I'd love to hear some good ideas. :)
I'd love to see a solution which captures the per-file versioning in a sensible way. In some discussions we have thrown around the idea of trying to line up MKS per-file versions by commit-time or something. That way we can formulate the concept of the "repo" evolving through a commit which contains changes in multiple files.
I use this tool to import change packages from MKS into Mercurial, import it to git should be quite similar; or you can import to Mercurial first, and use git tool to import Mercurial next.
https://github.com/arsane/py-mks2hg.git
It will try to find out all the change packages that under the specified project, and commit to new Mercurial repository in order.
来源：https://stackoverflow.com/questions/1314218/is-it-possible-to-import-an-mks-integrity-repository-into-git