Linus wrote git because BitKeeper was taken away from him due to the Andrew Tridgell incident, not because he disliked BitKeeper; he didn't even mind that it was closed source.
Found this article: https://www.pcworld.idg.com.au/article/129776/after_controve...
I wonder, how many people reading that article would predict the rise of stuff like GitHub and GitLab and the success of Git to the point of crushing CVS and making SVN decline in popularity?
CVS was already on the way out even prior to git's inception, because of SVN. SVN's unofficial goal is essentially to be a better CVS, and it was a great success on that front. However, IMO its success made its core dev team complacent.
For example, one complaint I hear often of SVN is that it's slow. Go use CVS for a week -- and I mean not just doing a checkout and make a few commits, but merge, diff, switch branch, add / remove / rename sub-trees, etc.; bonus points for involving >3 people trying to do the same simultaneously -- then try and tell me SVN is slow.
Nonetheless, SVN is not fast, but it's fast enough when there was no viable competition. Then git came along, and even the staunchest opponents must conceded that it's lightning quick. And people will tolerate a lot of BS from a tool if it does the job and does it quickly.
SVN's performance has improved significantly since the 1.4.x days, around the time when git first made its appearance. No doubt some improvements were on the roadmap regardless, but surely having competition lit a fire in getting them out the door.
Git is extremely well engineered, it's just that its UI is not conducive to learning it.
1) git log uses a pager by default and is lightning fast compared to svn log which needs a server connection and is not paged
2) the "current commit id" is the same across all directories in a repo, while in svn every directory can be at a different revision
3) side benefit of #2, a "git status" in a subdirectory also shows the status of files in upper-level paths of the repo
4) backup-ability: every git checkout is a full clone, so if the server is down, or you're on the road without wifi, you can still work even with history
5) partial commits (git add/commit -p) is a godsend, I don't get why svn still hasn't implemented this
6) the tooling around hosting is way better - websvn is a laugh compared to gitweb and even more so compared to gitlab/bitbucket/github
7) support for branches
I didn't dream of it in terms of GitHub.
In my experience most people are using git with a svn workflow. They use github (gitlab, or something internal to the company) as the central server, and work only from the central server. Make github speak svn, and alias all the git commands to svn and they couldn't tell the difference.
Yeap, but with a lot of local branches, and that makes a huge difference. Branching with SVN seriously sucked (although I've heard it's gotten better).
Depends on the business area. I am still using SVN in 100% of our customers.
And they don't seem keen to move into Git anytime soon.