Sell me distributed revision control

Question

I know 1000s of similar topics floating around. I read at lest 5 threads here in SO But why am I still not convinced about DVCS?

I have only following questions (note that I am selfishly worried only about Java projects)

• What is the advantage or value of committing locally? What? really? All modern IDEs allows you to keep track of your changes? and if required you can restore a particular change. Also, they have a feature to label your changes/versions at IDE level!?
• what if I crash my hard drive? where did my local repository go? (so how is it cool compared to checking in to a central repo?)
• Working offline or in an air plane. What is the big deal?In order for me to build a release with my changes, I must eventually connect to the central repository. Till then it does not matter how I track my changes locally.
• Ok Linus Torvalds gives his life to Git and hates everything else. Is that enough to blindly sing praises? Linus lives in a different world compared to offshore developers in my mid-sized project?

Pitch me!

Answer 1

Reliability

If your harddisk silently starts corrupting data, you damn well want to know about it. Git takes SHA1 hashes of everything you commit. You have 1 central repo with SVN and if its bits get silently modified by a faulty HDD controller you won't know about it till it's too late.

And since you have 1 central repo, you just blew your only lifeline.

With git, everyone has an identical repo, complete with change history, and its content can be fully trusted due to SHA1's of its complete image. So if you back up your 20 byte SHA1 of your HEAD you can be certain that when you clone from some untrusted mirror, you have the exact same repo you lost!

Branching (and namespace pollution)

When you use a centralised repo, all the branches are there for the world to see. You can't make private branches. You have to make some branch that doesn't already collide with some other global name.

"test123 -- damn, there's already a test123. Lets try test124."

And everyone has to see all these branches with stupid names. You have to succumb to company policy that might go along the lines of "don't make branches unless you really need to", which prevents a lot of freedoms you get with git.

Same with committing. When you commit, you better be really sure your code works. Otherwise you break the build. No intermediate commits. 'Cause they all go to the central repo.

With git you have none of this nonsense. Branch and commit locally all you want. When you're ready to expose your changes to the rest of the world, you ask them to pull from you, or you push it to some "main" git repo.

Performance

Since your repo is local, all the VCS operations are fast and don't require round trips and transfer from the central server! git log doesn't have to go over the network to find a change history. SVN does. Same with all other commands, since all the important stuff is stored in one location!

Watch Linus' talk for these and other benefits over SVN.

Answer 2

Most likely, no one will sell you anything here. If you need git's features, just git init. If it does not fits for you, just don't.

If you don't know git features yet, type git vs (note the ending space) in the Google search, and see the results from the autocomplete.

I preferred Notepad over IDE until I needed Netbeans features. Seems that this is the same case here.

As you know, there were many successful projects without VCS at all.

PS. Selling git violates its license! ;)

Answer 3

Your central argument about the IDE doing the tracking for you is false. Most IDEs don't in fact have any such functionality besides unlimited undo levels. Think of branches, merges, reverts, commit messages (log) and such and I bet that even the IDE that you did refer to falls short. Especially I doubt it tracking your commits - quite possibly on several different branches that you work on - and properly pushing them to the repository once you get online.

If your IDE actually does all that, I would in fact call it a distributed version control system in itself.

Finally, if the central repository dies for whatever the reason (your service provider went bankrupt, there was a fire, a hacker corrupted it, ...), you have a full backup on every machine that had pulled the repository recently.

EDIT: You can use a DVCS just like a centralized repository, and I would even recommend doing so for small-to-medium sized projects at least. Having one central "authoritative" repository that is always online simplifies a lot of things. And when that machine crashes, you can temporarily switch to one of the other machines until the server gets fixed.

Answer 4

Interesting question.

I'm not a seasoned DVCS user but my limited exposure has felt very positive.

I love being able to 2-step commit. It suits me.

Some advantages that spring to mind:

1. Better merge support. Branch-Merge feels more like a 1st class citizen in DVCS, whereas in my experience of centralised solutions, I've found it to be painful and tricksy. Merge tracking is now available in svn, but it's still slow and cumbersome.

2. Large teams. DVCS is not only for single-user commits. You can push & pull commits between teams before contributing back to the master repository (or not). This is invaluable for certain flavours of collaboration.

3. when working on experimental functionality, it makes sense to commit frequently, but only for the short-term. I don't want always to branch the main codebase, so it's nice to be able to play & re-record. Similarly, I can see it being useful when working with Continuous Integration. If I am working for days on refactoring efforts, I may break builds for an unacceptable timeframe, but I still want to keep track of my changes.

Note that my DVCS experience is more with Mercurial than with Git. Coming from a CVS/SVN background, I've found the learning curve much easier with Mercurial (Hg). Recently-added Google Code support for Mercurial is also a boon. ... I'll even go as far as to say, that my initial response to Git was negative, but more from a usability perspective than anything to do with DVCS