如何处理非标准的Subversion导入到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存储库的基础看起来像这样(基本上是前面'trunk'目录的副本).

- 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 如何看待分支和标签）。

总体来说，清洁度和完整性在进行此类迁移时，历史的幸运的是，它们都被高估了——它们都更能吸引我们的审美感，而不是实用的必需品。

编辑：清洁的侧面提示：使用--prefixgit-svn 上的选项，为导入的分支提供唯一的前缀，因为您可能会在 git 中拥有不同的分支约定，并且可以轻松查看 svn 历史记录。