如何git克隆从多个svn项目构建的单个svn项目 问题摘要（详情如下）

如何克隆一个svn项目，该项目作为单个项目存储库具有很长的历史，但它是由几个具有自己历史的项目合并而成的。使用svn工具，如果在项目融合之前或之后进行了修改，则可以无缝地访问文件历史的完整长度。这就是我们在迁移到git之后试图实现的目标

细节 和其他人一样，几年前我们已经从多个svn项目转移到单个svn项目。换句话说，我们是从这样的事情开始的

svnrepo/
   frontend/
      trunk
      branches/
         ng/
         ...
      tags/
         1.x
         ...
   backend/
      trunk
      branches/
         ng/
         ...
      tags/
         1.x
         ...

看起来像那样的东西

svnrepo/
    UnifiedProject/
        trunk/
            frontend/
            backend/
        branches/
        tags/

   frontend/
      trunk
      branches/
         ng/
         ...
      tags/
         1.x
         ...
   backend/
      trunk
      branches/
         ng/
         ...
      tags/
         1.x
         ...

请注意，尽管所有HAS文件已从svnrepo/submodule/trunk移到svnrepo/UnifiedProject/trunk/submodule，但原始组织仍然存在

在存储库级别使用一些SVN move命令保存所有历史记录（包括以前从CVS到SVN的迁移）。假设重组发生在日期D

自日期D以来，统一svn存储库积累了大量的信息。现在，我们正试图从这个svn统一存储库转移到单个git存储库。乍一看，这看起来比从多个svn迁移到单个git要简单得多。但在这种情况下，存储库的统一版本本身还没有历史记录

使用类似于git svn clone的命令http://svnrepo/UnifiedProject/ GitUnifiedProject乍一看效果不错。已检索到所有文件、分支和标记

但是，仔细查看文件历史记录，我们发现日期D之前的所有历史记录都已丢失。

git svn clone

命令没有看到来自同一服务器的不同项目的

svn移动

现在的问题是：如何从每个已移动的文件中检索完整的历史记录（甚至是日期D之前的历史记录）

另一个灵感来自于此
它在同一存储库的两个版本之间建立链接。我在项目的一小部分尝试了这个。比如说前端文件夹。这个前端与旧存储库的布局不同，它现在在UnifiedProject新存储库中的布局也不同。上面两个链接的结合似乎是一个不错的方法，但我还没弄明白如何做到这一点

也许另一种方法是直接从根目录克隆整个svn存储库。这将是巨大的，因为我已经过度简化了上述结构，其他非相关项目也在回购协议中。假设这是可能的。它是否会使以后的目标更容易实现，可以通过手动删除与UnifiedProject无关的所有历史记录和项目（cf和）

有人做过类似用例的实验吗
 我找到了一个工作流。
首先，使用所描述的技术，可以
git svn克隆每个单独的存储库
，并分别对它们进行重新组织，使它们看起来像是统一存储库中所期望的那样。
大概是这样的：

git svn clone --stdlayout http://svnrepo/frontend frontend
cd frontend
mkdir frontend
git mv !(frontend) frontend
git commit -a -m “Moving frontend project into its own subdirectory”

假设您有
git init
一些缝合历史存储库。然后在此回购中，您可以添加所有单个回购（例如：前端）。这里的重要选项是——允许不相关的历史记录

cd ../StitchingHistory
git remote add frontend ../frontend
git fetch frontend
git checkout -b feature/merge-frontend #You can also do this directly on master by omitting this command
git merge --allow-unrelated-histories frontend/master

对所有单个存储库执行此操作后，请确保在主分支上合并所有内容。然后，您应该有一个母版，该母版具有日期D之前的完整历史记录，并且恰好与您的回购后日期D具有相同的目录结构

有了它，你就可以在UnifiedProject开始之前，使用cherry picking（樱桃采摘）来粘贴缝合好的历史回购协议
 我找到了一个工作流。
首先，使用所描述的技术，可以
git svn克隆每个单独的存储库
，并分别对它们进行重新组织，使它们看起来像是统一存储库中所期望的那样。
大概是这样的：

git svn clone --stdlayout http://svnrepo/frontend frontend
cd frontend
mkdir frontend
git mv !(frontend) frontend
git commit -a -m “Moving frontend project into its own subdirectory”

假设您有
git init
一些缝合历史存储库。然后在此回购中，您可以添加所有单个回购（例如：前端）。这里的重要选项是——允许不相关的历史记录

cd ../StitchingHistory
git remote add frontend ../frontend
git fetch frontend
git checkout -b feature/merge-frontend #You can also do this directly on master by omitting this command
git merge --allow-unrelated-histories frontend/master

对所有单个存储库执行此操作后，请确保在主分支上合并所有内容。然后，您应该有一个母版，该母版具有日期D之前的完整历史记录，并且恰好与您的回购后日期D具有相同的目录结构

有了它，你就可以在UnifiedProject开始之前，使用cherry picking（樱桃采摘）来粘贴缝合好的历史回购协议
 因此，为了确保这一点，您保留了整个SVN monorepo，但希望在其中的一部分有一个git前端，以保存子树之外的历史，我说得对吗？不，我们希望摆脱SVN repo。所以整个过程是一次性的。SVN回购协议目前拥有历史上的单个项目，以及根据历史上的单个项目建造的较新monorepo。因此，SVN monorepo有几年的历史，加上我们将其用作多重回购期间每个项目的一组历史。这在SVN中不会引起任何问题，因为它支持通过不同的项目进行移动操作（这些项目只是实际repo根目录下的文件夹），所以这里要确定的是，您保留了整个SVN monorepo，但希望它的一部分有一个git前端，以保存子树之外的历史，我做对了吗？没有，我们想摆脱SVN回购协议。所以整个过程是一次性的。SVN回购协议目前承载着历史上的单个项目，以及根据历史上的单个项目建造的较新monorepo