无论开发人员对他们的当前项目托管提供商（GitHub、GitLab、GNU Savannah或不管怎样），随着时间的推移，新的产品会出现。网络的历史服务充斥着营业额，项目托管伪造了所有遵循这一必然趋势。但迁移的成本是强大：很容易设置一个新的项目主持人，比如GitLab，但您如何移动团队的整个结构代码、分支、注释、问题，并将请求合并到新的家？
Software Heritage，一家以归档为使命的非营利组织自由软件代码，当他们决定从Phabricator转移到更具活力的GitLab。有一段时间许多免费的开源项目都找到了Phalibor吸引人，但锻造厂已逐渐衰落2021年正式停止开发。
在OTS，我们开发了一个开源工具和框架，用于支持迁移到新的项目托管平台。我们用它将Software Heritage的所有项目从Pharmibor迁移到GitLab，但该框架足够健壮，可以支持迁移几乎所有项目宿主之间。
该工具称为福盖里。其目标是自动将项目从一个托管系统迁移到另一个。Forgerie可扩展到任何源和目标。它将项目托管平台的输入转换为功能丰富的内部格式，然后从该格式导出到目的地平台。
这与许多执行n到n迁移的工具使用的方法相同。例如，卫生保健领域包含许多不兼容的电子记录系统，因此迁移工具通常创建一种中间格式，以减少必要的格式转换数量。
OTS继续致力于Forgerie，作为其提供的将服务迁移到客户端。如果你想使用Forgerie，请抓住它从Forgerie的GitLab第页或接触我们如果您需要迁移方面的帮助。
本文的其余部分提供了一些关于伪造。任何解决类似问题的人都应该感兴趣项目托管问题，或者更普遍地说，对任何从事将结构化数据移动到新的数据存储中。多次迁移项目属于传统的提取、转换、，Load（ETL），但今天丰富的数据存储扩展了进入新领域。
福盖里
Forgerie代码由OTS开发人员Frank Duncan和根据GNU Affero通用公共许可证v3.0发布。这个帖子深入研究项目目标并对该项目的未来提出建议。我们来看看这一重大移民项目带来的困难以及我们如何处理了他们。这个故事可以为人们提供教训和提示处理各种数据迁移。
如果您使用了项目托管系统，您可能会想象即使如此有限的项目。伪造中的代码存在于多个分支中，每个分支由多次提交并通过合并进行增强。许多问题（更改请求）已由不同用户发布，以及评论这是指问题的数量。提交消息也链接并引用发行数量和分支机构。
需要一个通用的项目托管迁移工具
存在用于各种项目宿主的导入项目的工具平台，但它们是有限的。GitLab做得很好从GitHub和GitLab导入存储库允许上传私有存储库。本文稍后介绍我们将研究所有这些导入工具的一个特定限制：处理多个参与者。
要自动从Pharmibor迁移到GitLab，软件与开放技术战略（OTS）签订合同的遗产源软件咨询公司。初步研究发现了一些声称执行迁移的工具，但没有一个完成作业。而且每个迁移工具只能处理一个特定的锻造作为输入，另一个作为目的。OTS决定设计其作为通用转换器的新工具，可适用于任何源和目标存储库。
因此，迁移需要自动化工具在目标锻造，所有项目，分支，提交，合并请求，合并源中记录的问题、评论和用户存储库。如果可能的话，贡献者应该与他们的贡献。
OTS选择在Common Lisp中创建Forgerie，这看起来像是20世纪20年代的奇怪选择。但Common Lisp维护良好稳健。它对Forgerie项目的最大优势是Lisp数据库到字典的转换很容易。因为Pharmibor商店关系数据库中的数据，数据库到字典的转换自动化迁移的中心任务。
Forgerie项目有三个子目录：一组使用的核心文件通过所有迁移、Phalibor的出口文件和GitLab。此设计为未来的开发人员扩展通过添加更多入口和出口选项进行项目。例如，为了从Phalibor转到GitHub维护人员可以重用现有的核心和Phabricator目录。
阻抗不匹配带来挑战
所有伪造都提供基本的版本控制功能，以及沟通和管理工具，如问题。但每个锻造厂也是独一无二的。在这种情况下，邓肯必须决定如何最好地适应目标GitLab平台中不同或缺失的功能。
Duncan面临的最大挑战是GitLab将项目映射到存储库是一对一的，而Phalibor处理项目作为一个高阶概念。Pharmibor中的项目可以包含多个存储库，一个存储库可以是许多存储库的一部分项目。Phaubritor还支持多个版本控制工具（Git、Mercurial等）。使Forgerie足够灵活，以消除这些类型的数据结构差异是一个关键目标。
不同的项目方法引入了几个难题。首先，邓肯必须确保每条信息和票据指向正确的GitLab项目。
合并请求是最难迁移的元素，因为在Phabricator一个变更集可以跨越多个存储库。这个邓肯必须执行的要求是保持序列严格控制原锻造厂的事件，因此旧铸造厂发行了43期锻造厂仍然是新锻造厂的第43期。这样，任何电子邮件消息或者，提及该问题的评论仍然指向正确的问题。
许多细节需要整理。例如，Phalibor它自己的标记语言可以向评论和问题添加富文本。这个语言必须转换为Markdown才能将注释存储在GitLab。
多个贡献者的问题
当有许多人因他们的贡献而受到赞扬时进口工具有一个棘手的问题。正确授予学分是至关重要，因为许多贡献者将其声誉记录在案由他们的贡献提供。关于数量的统计他们做出的承诺，他们得到的“星星”等都支撑着他们就业和晋升战略。丢失信息也会使更改难以追溯到负责人。
另一方面，出于安全考虑，不允许某人进口材料并将其归于他人。
如果设置了输入存储库，GitLab就会解决这个问题右：执行导入的人需要主控或管理员访问权限，并且必须将参与者从输入存储库映射到目标存储库。如果访问权限不允许导入添加材料到贡献者的存储库，GitLab的导入可以准确地将问题属性为贡献者，但不提交。
Forgerie在保存贡献者来源方面走得更远：它跟踪Pharmibor用户并在GitLab中为创建用户记录在Phalibor存储库中的每个用户。软件遗产项目没有出现困难，因为没有出资人在GitLab中有一个帐户。确切地说确定了每个Phabrictor贡献者都不存在GitLab贡献者。如果GitLab有一个使用相同电子邮件的帐户地址作为导入的帐户，系统将发出错误并阻止Forgerie导入参与者的提交。
一些实现细节
Forgerie通过创建所有内容的日志来执行迁移发生在源存储库中，并在目标锻造。预制器使用经典的LAMP堆栈，存储所有存储库信息到MySQL数据库中。Forgerie对此进行了查询数据库以按顺序检索每个项目，然后调用GitLab API在那里创建项目。
对于那些特定类型的请求，每个请求需要一秒或两秒，以及当您计算所有项目时，存储库可以包含数万个项目合并、注释等。因此，您可以预期迁移需要24小时小时或更长时间。
长跑需要检查点并重新开始。当邓肯设计简单版的Forgerie让他只跑一次，他觉得自己如果失败，可以重新启动运行。后来他意识到23小时后重启变得不可接受。
日志通过一种简单的交易。您可以将迁移想象为通过三个阶段（图1）。在第一阶段，项目位于旧平台中但不是日志。在第二阶段，Forgerie将项目添加到日志。在第三阶段，物品安全装载到目的地平台，可以从日志中删除。如果作业失败用户可以从日志的开头重新启动它。
图1：记录项目从源平台移动到目标平台的过程。
事务的一个经典问题出现在日志中：假设物品刚进入目标锻造厂，但锻造厂没有在失败之前从日志中删除项目的机会。项目存在于目标存储库和日志中，因此当Forgerie再次启动，项目将再次添加到存储库。忘记开发人员不必担心这是因为插入是幂等的。第二个插入将覆盖第一个，不会损坏信息。
评估Forgerie项目
Forgerie代码库非常小，总共有2726行，划分如下：
•核心（共享）代码：350行
•预制器特定代码：1233行
•GitLab特定代码：1143行
没有永远存在的平台。GitHub和
GitLab正在不断发展，总有一天开发人员会决定他们必须拿起代码，并将其转移到一些新的工作方式。Forgerie试图让迁移过程尽可能轻松。
多亏了奥拉姆为了帮助起草这篇文章，感谢Jim McGowan绘制图表，感谢Software Heritage的Antoine R.Dumont贡献技术改进Forgerie项目。
