是否可以将 MKS Integrity 存储库导入 git 中？
我只需要源树及其历史记录。 我现在不关心需求/问题。 我用命令行玩了一下，看看是否可以获得主干和一些开发路径的更改包列表。 我认为应该可以为每个更改包提取差异，并使用它来重放自 git 中第一次提交以来的所有更改。 像这样的事情：
- 获取第一个提交并将其添加到git
- 获取下一个CP
- 获取CP的差异
- 应用差异到git工作目录
- 添加并将更改提交到git
- 重复（2.）直到最后一个CP
您还可以用检查点替换更改包（将对我来说足够好）。
一种更简单的方法是仅签出 CP 并添加/提交到 git。 但随后您将无法跟踪添加、删除、移动和重命名操作。
有谁知道如何从“si diff”获得统一差异？ 那已经有很大帮助了。
有任何想法吗？
编辑2：
添加了一个答案，显示我实际上是如何进行迁移的......
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:
- 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 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...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我无法发布我编写的实际程序，因为我不是在自己的时间里完成的。 不过，我可以发布我是如何做到的。 使用任何脚本语言重做它应该很容易。
我编写的工具一次仅迁移一个分支。 我会告诉它我想要哪个分支（例如1.21.1）以及分支中的开始和结束修订（例如4和78将迁移从1.21.1.4开始到1.21.1.78的所有修订）。 为了将所有分支都放在一个存储库中，我将提供 .git 目录以用于导入。
完成。
MKS 对其字符串使用某种 ASCII 编码，而 git 通常使用 UTF-8，因此在将元数据（用户名、评论、标签等）导入到 git 时请注意问题。
对于更多分支，请执行以下操作：
还有一件事：“si”是 MKS 命令行工具。 因此，您要么需要指定其完整路径，要么将其路径放入搜索路径中。
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.
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:
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.
MKS Integrity 的问题在于其独特的存储库，一切都驻留在其中：
由于这些数据可以按照自己的节奏彼此独立地发展，因此将它们全部导入到一个 Git 存储库中将是一个坏主意：您只能克隆 Git 存储库的所有内容（即使您可以限制该克隆的深度）。
这意味着您将获得所有文档，即使您只对代码感兴趣。
MKS Integrity 导出意味着首先定义多个 Git 存储库来充当子模块。
像往常一样，我建议只导入：
我不会将所有内容导入 一个 Git 存储库，除非您确信您的所有源都代表一个 作为整体开发的系统（而不是独立开发的几个“模块”）
这将是继续下去的方法。
不！ 你不会！ Git 将推断这些操作 .
这就是成为文件的优势 内容 VCS。
The problem with MKS Integrity is their unique repository in which everything resides:
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.
As usual, I would recommend only importing:
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)
That would be the way to proceed.
No! You would not! Git will infer those operations.
That is the advantage of being a file Content VCS.
FWIW，遗憾的是 si diff 目前不支持统一 diff。 有人要求对其进行更改，但目前还没有太多客户要求该功能。
免责声明：我在 PTC（该公司收购了 MKS）工作。
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).
这适用于检查点...
https://gist.github.com/2369049
不幸的是，检查点似乎是MKS 唯一真正有意义的事情 -> GIT 作为检查点实际上是最接近 GIT 称为提交的“快照”的东西。
MKS 有很多不兼容的概念（每个文件版本跟踪、与 GIT 分支不同的分支、检查点等），这些概念都可以彼此独立地发展，因此很难说出如何将合理的历史记录迁移到 GIT 中。 可能有很多方法可以做到这一点，但没有一种比下一种更“正确”。
也就是说，我很想听到一些好主意。 :)
我很想看到一个以合理的方式捕获每个文件版本控制的解决方案。 在一些讨论中，我们提出了尝试按提交时间或其他方式排列 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.
我使用这个工具将更改包从MKS导入到Mercurial中，将其导入到git应该非常相似； 或者你可以先导入到Mercurial，然后使用git工具导入Mercurial。
https://github.com/arsane/py-mks2hg.git
它会尝试找出指定项目下的所有变更包，并按顺序提交到新的Mercurial存储库。
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.