SVN到GIT迁移或：如何组织使用不同语言的大型仓库

时间：2017-08-30 08:45:44

标签： git svn migration code-organization

我知道这个话题已经出现过几次，但不完全符合我的情况。

我们希望使用Atlassian Stash / Bitbucket Server从SVN迁移到GIT。我们的SVN回购是一个＆＃34;上帝对象＆＃34;回购，它不是那么小。大约9年的历史，20,000次提交。

由于历史原因（...），结构就像

svn:/url/trunk1
-| C# Libs (Visual Studio solutions + dll files)
--| Hardware related
---| Products
----| a lot of different solutions here...
---| non products
----| different other solutiosn here
-| Equipment (VS solutions, no Libs)
--| Equipment A
---| Project A1 
----| trunk
----| branches
----| tags
---| Project A2
----| trunk
--| Equipment B
---| Project B1
----| trunk
----| branches
----| tags
---| Project B2
---| no trunk but VS solution directly
-| Products
--| Product group A
---| Product A1
----| trunk
-----| matlab code
-----| documentation
-----| embedded c code
----| branches
----| tags
---| Product A2
----| trunk
-----| matlab code
-----| documentation
-----| embedded c code
----| branches
----| tags
-| Schematic/pcb
--| again some subfolders followed by products

所以一团糟。有一个巨型trunk1，我们在Product-＆gt; Projects中混合了matlab + c代码（每个项目都有自己的trunk / branch）。然后有完全独立的文件夹用于pcb原理图和c＃dll库，尽管有一些连接到产品文件夹。

两个大问题： 1）你甚至会尝试将这整个事物迁移到（很多）GIT回购或者你会重组它吗？ 2）如何组织使用不同语言的回购，如matlab代码，嵌入式c固件代码和（松耦合）C＃代码？你是否为每种语言拆分了，当某个项目需要其他部分的回购等时你会怎么做？

非常感谢！

1 个答案:

答案 0 :(得分：2)

如何处理这种情况最终会要求您在利益相关方之间达成某种共识。好消息是，每个迁移到git的团队都必须处理这类事情。没有一个正确的答案，但是当我帮助团队完成这个过程时，我可以提供一些实际的思考和建议。

1。 Git是全有或全无

与颠覆不同，git克隆（如果你想让它可用）是一个全有或全无的命题。虽然您可以浅层克隆或检出仓库的子集，但这些功能仅用于部署目的，而非一般工作。

因此，使用一个大回购意味着每个克隆回购的人都需要为您已经版本化的每个项目下载9年的历史。

虽然git与旧版本控制系统相比速度惊人，但如果将数百万个对象放入其数据库中，它确实会受到性能下降的影响。

这意味着某种形式的分手必须发生才能正确使用。

2。你在哪里划线？

首先考虑你现在画线的位置。看起来您已经将回购分成了较小的部分，因为我在您向我们展示的内容中看到了多个主干和分支文件夹。

这可能是一个很好的起点。转到团队的各个成员，看看他们实际检查了什么，这将是非常有启发性的。

其他考虑因素包括您一起部署的内容，更改某些内容的频率以及组件之间的紧密耦合程度。有些项目可能最好分开，有些可能会更好地结合起来。

就组织而言，BitBucket允许您创建项目来组织您的存储库，其行为与您的文件夹非常相似。您最终会在这些行中命名为repos：bitbucket.mysite.com/equipment-a/project-a1.git

3。这对项目来说很棒，但依赖项呢？

看起来您还需要担心很多库和依赖项。有几种方法可以解决这个问题。

您可以在解决方案中处理这些内容，方法是检查依赖关系repos并使用符号链接将它们导入项目或通过IDE导入它们。但请注意，您的构建过程可以在以后找到依赖项。

稍微更现代和更优雅的解决方案是设置内部包服务器（例如，NuGet for c＃），并使用它们来存储可以提取到项目中的依赖项的版本化版本。此方法不仅允许您以熟悉的方式轻松访问库，还允许您在许多情况下逐步更新项​​目中的新版本。更不用说它将所有那些讨厌的二进制文件从你的回购中保留下来。

4。这个回购太多了吗？

是的，不，也许，也许不是。这里没有神奇的数字。显然1在您的情况下太低（可能是10）但是太高并不是由某个任意数字决定的（无论对你的老板多么可怕），但它是关于在真实和理想的，让你完成工作。我有一个数据库架构师曾经说过＆＃34;规范化直到它受伤，非规范化直到它起作用。＆＃34;这同样适用于此，找到一个平衡点，让您在没有过程妨碍的情况下工作。

我曾在微服务堆栈上工作过100个回购单个项目和大型单片电子商务网站只有1.两者对各自的环境同样有效。

关于其他好消息，你现在做出的决定并非永远。如果您发现它们太大或者您将事情分开太多，那么拆分或组合回收线是相对简单的，或者至少是实用的。因此，您现在可以做出最好的决定，并确保您不会被终身锁定。

摘要

您已经提出了很多正确的问题，并且似乎直觉了解了各种方法的风险和回报，所以我相信您会找到一个很好的平衡点。你的团队。最重要的是，让您的团队参与并确保他们对这些决策有所贡献。你可能想要订购一大块肘部油脂。

相关问题
最新问题