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服务器运行（以只读模式），以便在必要时可以用它来查找。

除了使用svndumpfilter排除Subversion的某些部分之外，我不知道有什么简单的方法来清理Subversion的历史记录。如果你很幸运，git-svn会神奇地做正确的事情，git log中的历史实际上看起来比svn log中的更清晰（由于git的看法不同）分支和标签）。

通常，历史记录中的清洁度和完整性是进行此类迁移时的两个相互冲突的目标。幸运的是，它们都被高估了 - 它们既吸引我们的审美观，也不仅仅是务实的必需品。

编辑：清洁度的侧面提示：使用git-svn上的--prefix选项，为导入的分支提供唯一的前缀，因为很可能你在git中有不同的分支约定，它会使它成为以后很容易查看svn历史。

如何处理非标准的Subversion导入到Git

1 个答案: