The Rise of Git 442
snydeq writes "InfoWorld takes a look at the rise of Git, the use of which has increased sixfold in the past three years. Buoyed in large part by interest among the Ruby community and younger developers, Git has been gaining share for open source development largely because of its distributed architecture, analysts note. And the version control system stands to gain further traction on Subversion in the years ahead, as Eclipse is making Git its preferred version control system, a move inspired by developers and members."
Bazaar (Score:5, Insightful)
Yet another DVCS article that doesn't mention Bazaar at all. And cursorily swats away Mercurial as "not as large a community."
It seems like just about every argument in favour of Git could be equally applied to any other DVCS. On top of that, the only thing it has going for it is a larger community (and being the creation of Torvalds).
I've argued to wit's end that Bazaar is superior to Git in a multitude of ways (branches as separate file-system directories, optional ability to work in bound mode as with Subversion, revision numbers, explicit notion of a 'trunk' versus merged branches, explicit moves/renames rather than heuristics, commit metadata). Basically Bazaar has a much richer data structure than Git. The last point (commit metadata) is crucial: because Git lacks commit metadata, it is impossible to meaningfully use any other revision control system in conjunction with Git -- what a selfish decision.
Yet all I ever hear is "Git is better than all the other revision control systems because [generic reasons why DVCSes are better than centralised ones]." Such is the case with Scott Chacon's site Why Git is Better Than X [whygitisbetterthanx.com], which I wrote a rebuttal of at Why Git Ain't Better Than X [wordpress.com].
Mercurial (Score:1, Insightful)
Re:Data, Images, Binary builds etc. (Score:4, Insightful)
Storing large volumes of binary data in an archived fashion is a job for a filesystem, not a CVS. A CVS is not intended as a backup solution, nor should it be used as such.
So when I want to release a critical patch to an old version of our software I shouldn't just be able to extract everything from the repo, make the change and build the release installer, I should also have to find where any required binary files for that release were stored and copy them to my machine and hope that no-one deleted them in the meantime?
I really know very little about git, but from the numerous 'Git doesn't do X, Y, Z', 'But you shouldn't be doing X, Y, or Z!' posts here I don't see a reason why I would I want to.
Re:Mercurial (Score:5, Insightful)
Mercurial's most touted advantage is that it's easier to learn, but this is a joke. If you develop, you interact with the version control system all day. A tiny advantage in learning it faster is nothing compared to not being able what you want to do afterwards, or having to redo something because the version control works against you instead of with you.
I work at a company that has used Git professionally. My team isn't dumb people, but they have fucked up with Git dozens of times. What I quoted is an okay argument at a personal level. However, there is something to be said as an organization that having an easy-to-use tools is better.
I am not making the argument that either Mercurial or Git is better; I am making the argument that tools which are easier to use will lead to less fuck-ups in an organization.
Re:Data, Images, Binary builds etc. (Score:4, Insightful)
and you've just screwed the entire configuration process there.
The whole point of a SCM is that you put your sources in there so you can check it out and get the same set of sources from any point in history. The moment you say "oh that's too big, we'll put it somewhere else" is the day you lose control of that reproducability.
Your images used in the app are part of the source. While there's a place for storing data elsewhere, it still has to be controlled in a way that you can get it back out again for a particular version.