Hi everybody!
Please let me share my point of view as of 2024. To give you some context, I've been working on Fisheye&Crucible for the last 10 years, both as a software engineer and a team leader. I wore the "product manager" hat as well. Also, over a decade ago, in my previous job, I was subversion administrator.
Now, let's get to the point.
My personal recommendation is as follows:
If you are still using Mercurial or Subversion then you shall migrate your repositories to Git.
Yes, it’s hard, especially if you have huge Subversion mono-repositories, as the most probably they will have to be split. But Git is the industry standard for a long time and this will be best long-term solution for your teams. Just have a look at public surveys, like done by StackOverflow or JetBrains:
By not migrating to Git, you're cutting off yourself from the entire ecosystem built around Git. And I'm not talking about Atlassian tools only, like Bitbucket, but about other tools on the market.
Think about developers IDEs, like Jetbrains ones. Most of them will have superior support for Git and very basic one for other source control management systems. Or about security scanners, like Snyk or Veracode. Or about automated dependency updates, like Renovate. Or CI/CD built around Git, like Bitbucket Pipelines or GitHub Actions.
When it comes to a specific Git-hosting solution, if you're using on-premise tools (as many Fisheye & Crucible customers do), then I recommend Bitbucket Data Center. It scales well and has very high performance and stability.
To help you a bit with a decision, please let me share my subjective, side-by-side comparison of Git and Subversion. I hope this table will help a bit to understand differences and how to find equivalent solutions for things you might be using in subversion:
| Area |
Git |
Subversion |
| Max reasonable repository size |
While there's no upper limit, I recommend ~1 GB and ~ 5 GB with LFS. Such repository is small enough to be quickly cloned on developer's workstations, in CI/CD jobs etc (assuming full clones).
|
Also no upper limit, but if you want to have mono-repository, it should not exceed ~ 1 TB. Of course, I'm assuming assuming partial checkouts from such repository, ~ 1GB in size.
|
| Checkout/clone optimization |
sparse checkout
shallow clones
partial clones
|
Checking out sub-tree. |
| Mono-repositories |
A bit challenging, but doable. |
Relatively easy as full checkout is never done. |
| Referencing other repositories |
git submodules |
svn externals |
| Distributed development |
Perfect |
Not really |
| Scaling server |
Very good, e.g. Bitbucket Data Center cluster, Bitbucket smart mirroring, Bitbucket Mesh, Bitbucket LFS, Bitbucket CDN, Bitbucket DC search server |
Not really, everything on one Apache server, one hard disk. The svnsync and read-only clones might help.
|
| Tooling support |
Great! E.g. Bitbucket, GitHub, GitLab, Snyk, Renovate, developer IDEs etc. |
Slowly deteriorating |
| Read access permissions |
Typically per repository for cloning/reading |
Per file (Apache access rules). |
| Write access permissions |
Controlling branches and pull requests (e.g. Bitbucket). Custom hooks (e.g. Bitbucket).
|
Per file (Apache access rules). Also via commit-hooks.
|
| Working with binary files |
git lfs file locking |
svn file locking |
I hope this helps. :)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.