How do I migrate a SVN repository with many projec

Question

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.

Our SVN repository currently looks something like this:

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

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).

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?

Answer 1

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.

• We are using GitBlit (not GitLab), but I don't think that this makes a difference.
• We have some distributed teams with bad network connections, so size may be relevant.

The following rules have helped us up to now:

• Git is normally used with smaller repositories. Anything that may be built independently from something else, or may be changed with a different release cycle, by different teams, should stay in different repositories.
• We have not used up to now sub-modules, here is a citation from a (German) book about Git usage in the company:

With Sub-Modules, you are able to include Git-repositories into other Git-repositories. ... Submodules are useful to divide big projects in independent modules.

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 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.

Try to do an experiment:

• 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.