> [...] 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.
Considering the architecture of the git and fundamental tradeoffs that you make after deciding on: content addressability, internal data representation, tracking content instead of files, taking snapshot of the content of entire commit as opposed to just its diff - the only avoidable BS people get from git is its "porcelain" CLI. There have been many tools tools to address it (like easygit).
Git is extremely well engineered, it's just that its UI is not conducive to learning it.
For me, there are numerous advantages of git over svn:
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
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.