git - 如何处理对 Git 的非标准颠覆导入

Question

我们有一个非标准的 subversion 存储库，我们想将其转换为 Git。问题是我真的不知道从哪里开始才能确保我们保留完整的历史记录但又不会搞得一团糟。

我们的存储库拥有我们公司产品套件过去 6 年的历史，并且经历了多次重组。在所有情况下，我们都有一个核心平台代码库，然后是几个以不同方式组合在核心平台之上的项目/插件。

前几年的结构如下:

-- plugin1
   - trunk
   - branches
   - tags
-- pluginX
   - trunk
   - branches
   - tags
-- trunk   (core platform)
   - <various sub dirs)
-- branches  (various feature branches of the entire repository)
   - refactoring1
   - refactoringX
-- tags (various tags of customer releases of full respository)
   - customerX_1.x  
-- vendor  (vendor drops and tracking of 3rd party source deps)
   - 3rd_party_code_A
   - 3rd_party_code_X

随着时间的推移，我们在根目录中添加了更多目录，包括:

-- releases (replaced tags; branches for released stable versions of repos)
-- sandbox  (area for misc projects of interest; should have been new repo)

然后我们清理了它并结束了:

-- trunk
  - platform
  - plugin1
  - pluginX
-- stable  (stable release branches of trunk)
  - 1.1
  - 1.2
-- tags    (release points; marks a point on a stable branch)
  - 1.1.1
  - 1.1.2
-- vendor
-- sandbox
-- releases (copies of old releases of interest)

这就是我们的历史。我们希望最终得到的是更干净的东西。现在我们正在考虑 git 存储库的基础，如下所示(基本上是先前“主干”目录的副本)。

- platform
- plugin1
- pluginX 

Branches:
  - stable/1.1
  - stable/1.2
Tags:
  - rel/1.1.1
  - rel/1.1.2

我们想将沙箱和供应商放入他们自己的存储库中。 (不知道该怎么做，但也许有一种方法可以只导入 svn 存储库的一个子集)

就分支和标签而言，我们希望来自“稳定”的代码最终成为分支，来自“标签”的代码最终成为稳定的标签。

对于原始结构中较旧的历史，我们希望保留尽可能多的历史，但又不想污染新的存储库。例如，如果我们可以回顾并看到在重构分支上发生的更改，那会很棒但不是绝对必需的。

目前我们正在讨论如何进行以及如何以干净的方式重组和导入所有内容。我们至少需要一种方法来了解之前两次存储库重组中的平台和插件代码的完整历史记录。如果可能的话，我们还想从最新的存储库结构中获取稳定和标签信息。

有人对如何执行此导入有建议吗？

例如:

• 是否可以保留整个重组的完整历史记录？
• 我们是否应该以某种方式重写 subversion 存储库以在导入之前清理它，如果是的话如何做？
• 我们是否应该导入完整的历史记录，然后在 Git 中对其进行重构？如何导入？
• 关于如何使此导入干净的任何想法？

Answer 1

根据您的情况，git-svn(使用默认的 --follow-parent 选项)可能会按原样执行此操作。您应该做的第一件事是尝试几次 git-svn 运行，仔细拼写出 -T、-b 和 -t 选项帮助它处理目录结构。

不过，您可能会遇到复杂的目录结构历史问题。

我最近处于非常相似的情况，将我公司的 Subversion 代码迁移到 git，其中 SVN 历史经历了与您所描述的非常相似的重组。就我而言，我还想将项目从一个 Subversion 存储库分离到多个 Git 存储库(每个项目一个)。

我能够采取简单的方法，决定迁移超过几个月的历史并不重要，所以对于每个项目，我确定 git-svn 可以优雅地处理的最早修订版，然后只从那里获取历史记录(使用 git-svn -r)。在处理过以前的 VCS 迁移(VSS 到 SVN，2005 年)之后，我从经验中知道很少有人提及长期历史。在任何情况下，很容易让旧的 Subversion 服务器保持运行(以只读模式)，以便在必要时可以使用它来查找内容。

我不知道有什么简单的方法可以清除 Subversion 的历史，除了使用 svndumpfilter 来排除它的某些部分。不过，如果你幸运的话，git-svn 会神奇地做正确的事情，并且历史在 git log 中实际上看起来比在 svn log 中更清晰(由于到 git 查看分支和标签的方式的不同)。

一般来说，在进行此类迁移时，历史的清洁度和完整性是两个相互冲突的目标。幸运的是，它们都被高估了 - 它们都更符合我们的审美意识，而不是实用的必需品。

编辑:清洁方面的小贴士:在 git-svn 上使用 --prefix 选项，为导入的分支提供唯一的前缀，因为您可能在 git 中有不同的分支约定，方便以后查看svn历史记录。