"[..]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.
I've actually found bitbucket slowly becoming a good competitor to github.
From a sales point of view, bitbucket's offering of 5 free private repos might actually help them attract more developers who are making proprietary apps and making money, and then more willing to pay for more repos in the future. I personally have quite a few repos there partly because I don't want the publicity of github (and partly because hg was quicker to learn than git :P). I also know a friend who switched to bitbucket simply due to the private repo offerings.
For open source though, github is probably the way to go.
This is all just anecdotal though, I'd love to hear some solid evidence if anyone has some.
Note that it's not 5 free private repos, but 5 private users. You can have unlimited private repos. So, in a small team you'd probably never have to pay. I wonder what has led them to this decision business-wise. Was the competition from github so overwhelming that they decided to counter it with with relatively drastic measures (giving up lots of $$$)?
ah yeah, I may be wrong, but I swear it started as 5 repos, then they changed it to users.
Anyway, for some reason one of my free accounts has unlimited users right now. Not sure how that happened but I think it might be because I had more than 5 users on a repo before they made the upgrade? Pretty awesome regardless.
In my experience, bitbucket has been extremely unreliable and creaky compared to github. I see frequent random unscheduled outages where the ssh connection won't connect, ssh won't authenticate, or hg won't respond from the other side. The web interface also caches a lot of stuff too long; I've seen it take a few minutes for its idea of "tip" to refresh after pushing new patches, and stripped revisions linger in the log view for similar amounts of time. Hopefully now that Atlassian's bought them the service quality will improve over time.
> Hopefully now that Atlassian's bought them the service quality will improve over time.
Given the growth of the the bitbucket team thanks to atlassian, I do think it will improve quickly. (I'm not even sure there was more than one full time person working on BB before)
This is precisely what happened to me, and the reason I ditched git for Hg in my most recent project.
I am not doing anything large enough to warrant paying for a GitHub account at the moment, and its not because I am cheap - its because I am a poor South African, and $7 a month is infinitely more expensive than $0 a month.
Github has "won" in that it's the current darling child of the code-hosting industry. It's done this for two reasons:
1. Git is superior to its competitors as a technology for use by developers. It isn't very much superior these days, but it is enough to be noticeable and preferred. This is a superiority in use and performance, which are enough of an edge to offset its architectural failings.
2. Github has better UX than the competition: I've been referring to code hosted in bitbucket frequently, and I often sigh at what they're doing. Getting to any given piece of code takes longer and requires more clicks than on Github. Github also has great features for understanding how code is moving within a project, and I find them more comprehensible and useful than the competition's.
It doesn't hurt that Github is a small self-started company with a staff full of brilliant people and a talented support staff. They certainly win the personality part of the competition thoroughly.
I'm not sure I'd say it has "won" - such a phrase implies a long-term positioning at the front of the pack, and those that came before it for code hosting (SourceForge, Google Code) enjoyed their time in the spotlight before having something new come along.
BitBucket in particular have made a good attempt after the Atlassian takeover, with the infinite free private repos being the most interesting part - I use it a lot, but mostly because I do a lot of small personal projects, and so the "social" features of GitHub - those which benefit most from its prominence - are mostly meaningless to me.
I don't believe there will ever be a clear "winner" because the landscape is constantly changing. Sourceforge was THE place to store your OSS code and provide downloads and there was a really great broad selection of code and a way to discover it. But they didn't build good ways of managing it and the whole experience became cluttered and confusing. I saw many projects move to Google Code who provided a clean interface.
And now I see many of those projects move to github and everyone I know is a big fan of the forking and pull requests.
But the landscape will change again and github keeps needing to iterate and innovate on their product. Just about every time I use github, I curse their disastrous search. There is just so much innovation they could develop around code management which they don't have, a competitor could jump in and they too could become the darling of the development world. They too will have "won".
When I started developing my product two years ago, I seriously thought about throwing my product into the source code hosting ring. I knew I had a product that could compete but as you pointed out, the landscape is constantly changing and it is also one of the places where you have compete by price.
Look at the recent shift by Bitbucket after being purchased by Atlassian. Bitbucket can now afford to be a money pit so that Mercurial can gain further adoption. Atlassian is really trying to build an enterprise solution around Mercurial (they've said this publicly) so they don't care if they lose money with Bitbucket. And this is going to affect Github. Only time will tell how much of an impact this is going to have.
So yeah I'm glad I decided I didn't want to get into this market space. I decided I was better off focusing on developing the innovations and be a complimentary asset for sites like Github, Bitbucket, and other hosting sites instead. My product certainly has overlap with some of the things that Github and Bitbucket has, but it's not designed to be a hosting solution. It's more of a competitor for Atlassians Fisheye and Fogcreeks kiln.
It occurs to me just now that it's kinda weird that subversion repositories are pretty much distributed everywhere; git repositories generally end up on github.
That's probably because with a distributed system, there isn't too much downside to everyone relying on a central service. If Github goes down, you can be up and running at a new host in 5 minutes.
My comment was more of an observation rather than a telling point for or against git, but I don't think it's a huge advantage of git that everyone has a backup copy of the repo that can be used for failover. github is essentially a central point of failure for many teams. You're going to change the location your CI checks out from if github goes down? Are you using github for issue tracking? Code reviews? What's more likely, I think, is that you just wait for a few minutes or hours until it comes up again, which is what you'd do with svn.
I think that Github is a big factor in git's success. If you use git and stick a project on Github, you just send people the Github URL, and BAM! they see your code and README file, neatly presented on one page. And since Github is so popular, this lowers the barrier to entry for other people to contribute patches, which is always nice.
If Github is bringing people to git, then it stands to reason that a seemingly disproportionate number of git users would use Github.
I started using bitbucket a month ago and everything went fine. I'm new to version control and selected mercurial as my VCS, so I was happy by finding a github counterpart.
I think it's wrong to compare bitbucket to github. You won't move to github because github is superior, but if you want to move to git, you'll probably do.
Bitbucket has all I need. I don't think I need any other fancy features, I already get things done the right way. I'm using the free version, but would upgrade if needed.
Also, make sure you read the down times before you argue about it:
"Bitbucket will be unavailable for approximately two hours starting Monday, Nov 1st, 01:00 GMT for a kernel upgrade."
I normally shy away from writing provocative information-light rants. The important parts (for me):
1. github is a social service, or perhaps best used as a social service
2. it has "the momentum", which is paramount for social services
3. git has "the momentum" wrt adoption of dvcs
There are assumptions implicit within these arguments that I've accepted, based largely on the summation of 'soft' and anecdotal evidence that has built up over the last couple years. People are right to challenge them, and right in their criticism that I take them at face value.
Disclaimer: I've only used Github for projects where either I'm the only coder, or where someone else was the only coder and I was just handling some release management stuff. So I've not experienced the full glory of collaboration via Github.
Am I the only one who is not particular impressed with Github? It seems OK, but not in a different league from other code hosting places the way many make it out to be.
I think it's main neat feature is to be able to click a button to fork. Many others have this now but, iirc (and my memory my be faulty), github was the first. At least the first I saw. That alone makes it easy to fork, fix, pull request. I'm a bit of a github fanboi.
The Linux kernel has its own fairly elaborate and entrenched system for handling their source; Github, as lovely as it is, just wouldn't be a good fit for them.
As others here and in the blog comments have pointed out, this post is semantically incoherent. But it was worth reading for the reference to hg-git alone. Cool stuff!
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.)