For a project like LLVM, it just doesn't matter too much. git-svn or plain svn works pretty well for most people.
Certainly it matters, and it'll move eventually, but i'd rather see time spent on better testing tools than a "better" vcs.
When i moved GCC from CVS to SVN, it made life a bit easier but it's not revolutionary change.
Which is funny, considering how often people argue about VCS systems.
Before we moved to Git, Roslyn was on TFS, which was basically Perforce/CVS/SVN.
You're absolutely right that the distinction among the former VCS's is minimal. However, Git offers value that was transformative compared to the former. Namely,
1. Git allows you to easily switch between multiple work items while keeping track of the work done in each item.
2. Git allows you to easily integrate with people who have significantly diverged clones of your tree without too much trouble.
3. Git allows you to easily work offline.
(1) is definitely the largest benefit, but was mitigated with tools like g5 when I was at Google. However, the Google gravity well has its own drawbacks.
(2) is very important if you want to host rapid release schedules with divergence of features. It's especially useful if you want to have long stabilization periods and low-risk bug fixes delivered in parallel to multiple customers.
(3) is pretty self-explanatory, but for most people it's underestimated how much downtime your VCS has. I'd bet, for most people, it's significantly less than 5 9's. Not only is that wasted time, it's frustrating because it's usually consecutive and removes entire working days at random.
I take it you haven't actually used the tool that was mentioned in the comment you replied to, namely git-svn? My use of svn to interface with projects using Subversion has essentially entirely been replaced by git-svn, and I can say it is essentially
impossible for someone who has used it to not realize that at least offline now works like git. Taking a step back: at some point what you run on the server is just a storage format; unless you used some of the more advanced Subversion features (at which point you might actually like using it), it generally maps pretty directly to git semantics, at which point essentially all other functionality differences are mere porcelain.
Not a big surprise, considering that SVN is "CVS done right".
Compare that to Git's author: "Subversion has been the most pointless project ever started. There is no way to do cvs right."
Git and Hg (+ the many tools that surround them: GitHub, Bitbucket, Gerrit, GitLab, etc.) have a model that makes community contribution far easier than CVS and SVN.
The community contribution concepts in git are great, but it is confusing to then mention GitHub: their modus operandi is to provide tooling to make things easier that are only hard if you insist on misusing git as if it were Subversion (by for example having a single centralized repository with multiple committers, requiring complex and annoying access control and public key management). If someone had built tooling like GitHub around Subversion and then encouraged use of svk (note the "k"; this was a replacement client for Subversion that supported offline operation and had better merging support, but which worked with any svn server), things would have felt much more reasonable before; the irony is that if you follow the actual git workflow used by Linus for Linux (where everyone has their own repository, rather than at best their own branch and at worst trying to share master), you shouldn't even need any of that for git :/.
Yes, and the centralized version comes from a tree that in the Linux workflow is only able to be modified by one person. You submit patches via email or pull requests (literal ones, to pull from a repository); you don't share commit bits on a centralized repository.
When i moved GCC from CVS to SVN, it made life a bit easier but it's not revolutionary change.
Which is funny, considering how often people argue about VCS systems.