如何将具有许多项目和通用库的SVN存储库迁移到Git/Gitlab? [英] How do I migrate a SVN repository with many projects and common libraries to Git/Gitlab?

问题描述

我们正在考虑从SVN迁移到Git/Gitlab，但是我想从任何做过此转移的人那里获得一些建议，以了解以下两个工作流程中哪一个最适合我们，或者是否有更好的方法做到这一点.

We're contemplating a move from SVN to Git/Gitlab but I'd like some advice from anyone who's done this move before as to which of the two following workflows would work best for us or whether there is a better way to do this.

我们的SVN存储库当前看起来像这样:

Our SVN repository currently looks something like this:

\tags
    \product1_v2
        \product_1
        \common
    \product2_v1
\trunk
    \product_1
    \product_2
    \common

据我所读，使用git的正确方法是将product_1，product_2和common分成单独的存储库.我读过许多文章，建议使用submodule或subtree是链接到我的通用代码的良好策略.与将我们的所有代码都放在一个存储库中相比，这两个听起来都非常麻烦.

From what I've read, the correct way to use git would be to break product_1, product_2 and common into separate repositories. I've read various articles which suggest using the submodule or subtree are good strategies for linking to my common code. Both of those sound like a lot of overhead compared to simply putting all our code in a single repository.

通常来说，我们会同时更改各种产品和公共库(我们的公共库仍在不断发展).

Generally speaking, we make changes to the various products and the common library at the same time (our common libraries are still evolving).

我知道gitlab有一个项目概念，但是对于多个项目是否可以共享一个存储库(如果我们将所有代码都放在一个地方)，我找不到确切的答案.

I know gitlab has a concept of projects but I can't find a definitive answer as to whether multiple projects can share a repository (if we were to go for all the code in one place).

所以我的问题是；您建议使用哪种方法来减少开销和头痛?

So my question is; Which method would you recommend to produce the least amount of overhead and headaches?

推荐答案

我对此没有确切的答案，但是我们的方法类似，所以我想分享一下我们已经做过的事情.

I don't have a definitive answer to that, but we are on a similar way, so I would like to share what we have done already.

• 我们正在使用GitBlit(不是GitLab)，但是我认为这没有什么不同.
• 我们有一些分散的团队，它们的网络连接不良，因此规模可能是相关的.

以下规则到目前为止对我们有帮助:

The following rules have helped us up to now:

• Git通常用于较小的存储库.任何可能独立于其他事物构建的东西，或者可能由不同的团队以不同的发布周期进行更改的任何东西，都应存放在不同的存储库中.
• 到目前为止，我们还没有使用过子模块，这是(德语)一本书中有关公司中Git使用情况的引文:

使用子模块，您可以将Git存储库包含到其他Git存储库中. ...子模块可用于将大型项目划分为独立模块.

因此，取决于整个代码库的粗略大小，并且如果所有人都在同一个团队中工作并且始终需要所有文件，则无需拆分存储库.之后有一些可用的食谱.

So depending on the rough size of the whole code base, and if all the people are working on the same team and need all of the files all of the time, there should be no need to split your repository. There are recipes available how to do that afterwards.

GitBlit具有项目"和存储库"的结构，并且它们是分层的.我试图为GitLab找到类似的东西，这是我能找到的最好的.那里的项目似乎类似于存储库.

GitBlit has the structure of "projects" and "repositories", and they are hierarchical. I have tried to find something similar for GitLab, this was the best I could find. There the project seems similar to be to a repository.

尝试做一个实验:

• 在存储库的主干上执行git svn.那可以管理吗?大小如何?
• 尝试使用命令的不同参数.查看存储库的大小如何变化，具体取决于您要迁移的历史记录的大小.
• Do a git svn on the trunk of your repository. Is that manageable? How about the size?
• Try the different parameters of the command. See how the size of the repository changes, depending on the size of history you want to migrate.

因此，最后，我将尝试仅使用一个存储库，因为我没有看到任何拆分它的理由.只要是这种情况，就坚持下去.因此，您可以保留大部分开发过程，构建过程，然后在以后进行调整.

So at the end, I would try to use only one repository, because I have not seen any reason for splitting it. And as long as this is the case, stick to it. So you can keep most of your development process, your build process, and may adjust it later then.

这篇关于如何将具有许多项目和通用库的SVN存储库迁移到Git/Gitlab?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！