I am doing an analysis - is Git the most widely used VCS. So, my question is if you are using something other than Git, what are your reasons?
Sorry, but I think the only reason to use SVN is bad integrity of old projects.
At my current company we are using SVN mainly just because most of the people does not want to learn new/different stuff. We had tried to propose migrating to Git couple of times but there was always pushback.
Outside I as using Mercurial some years ago but completely switched to Git and it was for the best.
Same reason as others. My previous company was stuck with SVN and to invest time and money to move to Git was something they weren't interested in. My current company on the other hand (a startup) has been actively using it since 2012.
I'm using SVN in my current company.
In my previous company we used SVN. The reason is similar to what @rajkumarpb said. In big companies, if something works then it doesn't make sense to invest time and efforts to upgrade the system (unless there are serious problems). So, for me it was svn at work and git outside.
SVN, because my company use SVN for last few years and even after explaining them about Git and it's pros, they don't want to make such a drastic change. So it's simple, I have to use SVN because I'm forced to. Outside of that, I'm using Git for all my other works!
Fullstack Developer.
Hey Ho
Yes, there are.
The main reason to use other VCSes such as Subversion (SVN) or Mercurial (Hg) is the fact that the pros of Git in some cases are not worth it. It becomes clear if are an expert and understand the real practical cons and downsides of using Git.
First of all, Git is overcomplicated. Most of the actions that are a bit more complicated than doing a regular clone, commit or push and pull are way too harder to perform and are too time and brain consuming. Instead of being a little helper and source code time machine for your code, Git becomes a time eater. VCS is just a tool that should help you. Instead of this, Git becomes the best procrastinator's tool to make excuses like
On the other hand, Mercurial or Subversion are less complicated, and they just work.
Version history is not safe in Git. It is possible that regular user operations will result into vanishing of your precious code history. Say you have a branch that was never merged to master. It contains some interesting work, and you decide to remove it. In Git, the branch and its code will be eliminated forever and entirely without any traces or possibility to recover. Other VCSes work differently and most of them
Git is not capable of storing binary content. It's simply not designed for this. It does not support locking; it does not work well with large repositories (you will definitely have a large repo when you begin storing your binary assets or builds in Git repository).
There is no access control in Git. Git does not have any access control features built in by design. There are plug-ins for Git that enable simple access control features, but since Git has a distributed design, they don't work as good as built- in access controls in centralized VCSes.
And these Git downsides and cons are just a tip of an iceberg. To learn more, read these articles that point out problems that you may encounter when you use Git as your content tracker: