We run several SVN servers (old world) and now a GitLab server (new world). It is not planned to migrate the SVN repos to Git (so far).
The old projects (SVN) are still maintained by the same people, which will also work on new projects (GitLab) in the future. Some staff will very likely never work with SVN anymore, hence only committing to Git.
There arose the idea to use GitLab to do code reviews on changes of the old projects (SVN) without really working in Git and therefore we thought SubGit could be handy.
Matter-of-factly we have Git repos without SVN relation (all the new stuff) and we would have Git repos as mirrors of SVN (very like no commits from the Git side, only from the SVN side). We intend to only use GitLabs code review features, which are very handy (instead of installing Reviewboard or similar for the SVN code part).
As I understood the license limits, all commits to all Git repos, also the SVN unrelated on the same server, will be blocked once the Git committer limit is exceeded. Did I understand correctly?
Consequently, since we generally move from SVN to Git over time, we will get more Git committer (SVN unrelated) and less SVN committer, bringing us into the situation, when we run SubGit due to the last single SVN repo mirror, and having everyone working on Git(Lab),
we will have to upgrade the license with the total number of Git committers
or map all Git users to the max. the number of licensed user to SVN user e.g. 49 Git user to max. 25 SVN user for a 25 user license.
Is that assumption correct?
Or is there another solution (installing two GitLab server it do not see as an valid option for us, we want to use the same GitLab instance that we already run, otherwise we could setup a server with ReviewBoard)?
The main point is that SubGit is activated for each repository individually, so it doesn’t block pushes to the Git repositories that are not mirrored to SVN, even if they are on the same server.
However, as you are gradually moving from SVN to Git, it’s quite possible (and very convenient), that some repositories may be accessed both from SVN and Git sides.
For example, the migration could take the following steps:
a) a repository in SVN, that everyone works on;
b) SubGit mirror between this repository and a Git repository in Gitlab is established;
c) the GitLab side of the mirror is used for code review only;
d) some developers move to GitLab and start pushing to the mirrored Git repository there;
e) all developers have moved to GitLab;
f) the SVN server is not used anymore, and the mirroring is shut down.
For some reason, step “D” on this list is not mentioned in your description of your migration process. Instead, you seem to assume that developers who move from SVN to GitLab will be using new repositories, not the mirrored ones. Is that so and why is that?
I should also note, that we provide a discount for license upgrades if more than 6 months of the maintenance period were left unused. So you might start with a smaller license and upgrade it as more developers are moving to GitLab.
It is good to hear, that it is not blocking pure Git repos.
Concerning point d):
The notion was to use the GitLab code review feature.
Since we are coming from SVN (I myself had sometimes a hard time to learn Git first and I am still not proficient) I feel SVN does not provide as many features and is therefore simpler.
The point was simply, keep the old world with the old tool until they reach their end of life and do the new stuff in the new tool chain (this is not only GitLab).
But over time, there might be a good chance, that people which embraced Git and still have to maintain old projects might do it via Git and SubGit.
We also extensively use svn:externals between repos (from a framework repo into the product project repos). We would have to resolve that all, to fully migrate to Git.
Let’s what the future brings.
But it is good to understand that pure Git repo commits are not affected resp. do not affect the mixed Git-SVN repos committer count.
It’s quite clear now, thank you. So there’s more than one thing SubGit can help you with :-)
Regarding svn:externals: SubGit does not translate that directly from SVN, but as you are setting up new repositories in Git, you might want to check out our new tool, Git X-Modules. It was designed to replace the missing :externals functionality in Git.