"[..]but just as distributed vcs' had won over svn a few years ago,"
This is an odd statement, which deserves more explanation. DVCSs have won in the arena of early-adopter programmers who actually care about these things enough to read them, but I'd guess that the number of SVN users still trumps the number of git/hg users by several orders of magnitude. Moreover, I'd guess that the number of programmer who have heard about git/hg is incredibly small as well (compared to SVN or other systems.)
By the way, hg has definitely won me. I use it with an online project management and hosting service called Codebasehq.com, which I recommend any time this comes up - I really love their interface, and their pricing options (you pay per project, which can have several repositories tied to it; you can even have several hg repos and several SVN repos tied to the same project, which is what I do.)
Yes, you are completely correct. It was such a PITA to switch from microsoft's visual sourcesafe to svn in the company I work for. That happened cca. 6 years ago. My coworkers were so entrenched in their ways that they mostly simply refused to listen to anyone, least of all to me. I was baffled then, but I think I know what is the problem: making a change to a work process means a certain amount of effort from all participants in that process. And people don't want to bother with new stuff exactly for this reason.
Needless to say, even when we finally switched to SVN, we still had problems. Coworkers mostly didn't read the svn manual or didn't care to understand what SVN is or does. My mailbox was literally burning with semi-hostile messages and for weeks I couldn't do anything except sit at coworkers' desks and explain the same thing over and over ...
I think it's mostly about risk aversion. I've seen the exact same thing trying to push SVN over VSS. No one honestly thinks that VSS is the superior product, but once you have 5 plus years of history with it, it's what you know, and no matter what the reasons are, that is a risky proposition.
We're talking about people who would never shave a Yak because they'd wrangle 100 hairy Yaks than spend 20 minutes reading how the automatic Yak shearers work.
Well, yes, that's probably ultimately true in a lot of cases, but if you approach it constructively, you have a much greater chance of success than if you just assume laziness.
Anecdote is not the singular of data and all that, but at the major game development studio I work at, no-one at my team has even /heard/ of git, and when I try to explain what a distributed version control system is I get blank stares.
Do they use perforce? It seems to be rather popular in the game industry, in part because its model suits projects that have a lot of large binaries in their repository.
Of course -- everyone in games seems to use Perforce. There are no better alternatives, including p4-git, and believe me, I've looked. Subversion is passable but slow.
Even though I use git for all my personal stuff, if I started a console or PC studio, I too would be setting up a P4 server the first week rather than even experimenting with git.
As you say, it seems to be the only code-oriented VCS that also comfortably handles large files (especially larger than available memory) with reasonable speed.
Traditional version control systems consider giant files a user smell.
Many (read: almost all, I'm willing to bet) web developers will be completely ignorant of trends in embedded programming. Many (read: almost all, I'm willing to bet) embedded programmers will be ignorant of trends in web programming. It is unsurprising that many programmers who do the overwhelming majority of their work in the closed-source arena would be unaware of trends in the open-source community.
I would go so far as to say something shocking that the number of actual coders NOT using any kind of version/source control exceeds those that do. This based on working in and managing 7 "shops" in the last 19 years. Education about VCS is slow and wearisome often when what you love is simply a 9-5 job for others.
I'm curious about what a team based workflow looks like without VCS, I'm really struggling to see how you could work without one. Can someone who's seen this enlighten me?
My company still uses SVN, but I'm in the process of migrating my teams projects to Mercurial. We aren't IBM, but we aren't small, either. I think that DVCSs are starting to make headway into "cutting edge, but not bleeding edge" companies.
As to Mercurial vs. Git, whatever. That argument bored me two years ago. Mercurial is, in my experience, easier for SVN users to pick up, but just use whatever works for your situation.
I actually consider primitiveness (insofar as it means simplicity) to be an advantage in collaboration tools like VCSes and ticketing/bug systems.
I currently work, for the first time, at a shop that uses git, and the closest thing we have to a git expert/evangelist has been complaining about how much hand-holding of developers he's had to do, especially as the company grows.
I like to point out that it's not the job of these developers (and web designers and a sysadmin) to become experts in a VCS, so one which is complex enough that it can't be effectively (if not fully) used by someone with just a passing knowledge, is bound to waste more time than it saves.
My other allegation is that git is not targeted at startups, which are, typically, very non-distributed collaboration environments. I like to gibe that Linus is the only target, but git does strike me as much more geared toward the decentralized development model of open source projects.
It may take some time, but git & hg are doing it the smart way with the likes of git-svn and hgsubversion.
Moving from one vcs to another usually meant 1) a difficult and error-prone history conversion process and 2) a cold turkey switch to a new way of working. That's a recipe for resistance and frustration.
If the incumbent is svn, early-adopter types can start using git-svn or hgsubversion right now, and can convert others one-by-one if and when they're ready.
This is an odd statement, which deserves more explanation. DVCSs have won in the arena of early-adopter programmers who actually care about these things enough to read them, but I'd guess that the number of SVN users still trumps the number of git/hg users by several orders of magnitude. Moreover, I'd guess that the number of programmer who have heard about git/hg is incredibly small as well (compared to SVN or other systems.)
By the way, hg has definitely won me. I use it with an online project management and hosting service called Codebasehq.com, which I recommend any time this comes up - I really love their interface, and their pricing options (you pay per project, which can have several repositories tied to it; you can even have several hg repos and several SVN repos tied to the same project, which is what I do.)