2017-09-16 39 views
1

我们公司已经决定从ClearCase的迁移我们的源代码与git,这是伟大的:-)创建git的历史,blob和树对象,并行

我知道,ClearCase和git的是完全地不同的源代码管理系统。 但是我们的开发者只会有一个包含完整历史的SCM。

我collegue发现下面的工具,我们的进口ClearCase的历史到混帐:https://github.com/charleso/git-cc

不幸的是我们的代码有超过46000个的源代码文件和历史进口超过10年。

我分析了这个工具,在我看来有两个瓶颈。 第一个是从clearcae服务器导入文件。这很容易通过多线程来解决。 第二个是git-cc本身的工作流程。

  1. 通过cleartool lshistory获取主分支的历史
  2. 创建文件和他们组的变更,以COMIT的
  3. 获得来自呼叫控制服务器文件(S)的指定版本,并复制到工作目录
  4. 混帐添加。
  5. git的承诺
  6. 挑选下一组和3再次启动

我想我可以通过使用低级别的git命令,并使用多线程改善。

每个comit-group查询它从服务器的变化并在git数据库中创建一个blob对象,因此它可以运行多个线程中的多个组。 另外我有一个线程,从刚刚创建的blob对象创建git中的历史记录。

我的问题是现在,这对你有意义吗?或者你认为我是naiv?

我忘记了任何git锁定机制吗?

您有任何其他想法?

+0

通常为了导入你使用[git-fast-import](https://git-scm.com/docs/git-fast-import)。我不知道它是否利用多个CPU(可能不是,因为它将所有数据作为单个二进制流),但至少它不会执行任何额外的IO。 – max630

+0

@ max630 嗨max630,谢谢你的回复。这是避免任何额外I/O的好处。我会评估它。 – jungnick

回答

0

在Git仓库的同一分支中使用多线程导入提交是有风险的(除非像你说的那样创建“blob对象”,即可以重放的补丁)。

但是,在不同分支上使用多个线程进行提交是可能的:您创建不同的回购,每个回收分支导入,然后您可以将这些回收取回到一个常见回购库中,并使用git replace or grafts重新附加回购。但是请记住:每个Git仓库都是一个组件,所以如果你的巨大ClearCase Vob包含多个组件(文件组),最好将它们分成多个Git仓库,而不是试图创建一个巨大的Git仓库组件。
我在“ClearCase to Git migration”中详细说明。

+0

嗨VonC,感谢您的回复。 我不知道为什么它应该有风险并行地创建blob对象? 并行导入提交显然是非常危险的,因为我想使用一个专用线程,从blob对象构建我的历史记录。 最后,我有n个线程阅读我的clearcase历史记录,并创建悬空的blob对象和一个专用线程来构建我的历史。 另一个团队正在评估我们如何将我们的VOB结构迁移到多个更小的回购站。目前我们评估子模块和子树 – jungnick

+0

@jungnick我在这里描述子模块和子树之间的区别:https://stackoverflow.com/a/31770147/6309。并给出一个子树的例子:https://stackoverflow.com/a/24709789/6309。我更喜欢子模块,因为我可以参考历史中的一个固定点,允许将父代回购克隆到已知状态。 – VonC