> With a DVCS, though, we have a problem. You do have the whole history at any given point, which in turn means you need to have every version of every blob. Bu

> With a DVCS, though, we have a problem. You do have the whole history at any given point, which in turn means you need to have every version of every blob. But because blobs are usually compressed already, they usually don’t compress or diff well at all, and because they tend to be large, this means that your repository can bloat to really huge sizes really fast. You can shallow clone a repository in git. This looks more like 'What should be the default mode for a source control : Centralized or Decentralized ?'. I think it should be decentralized since it requires more discipline. > Git is so amazingly simple to use that APress, a single publisher, needs to have three different books on how to use it. It’s so simple that Atlassian and GitHub both felt a need to write their own online tutorials to try to clarify the main Git tutorial on the actual Git website. It’s so transparent that developers routinely tell me that the easiest way to learn Git is to start with its file formats and work up to the commands. This could simply mean that it is am amazing piece of technology that everyone loves to talk about it. It could also mean that it is a bit more complex, but that doesn't mean that the complexity is not worth the benefits. > There is one last major argument that I hear all the time about why DVCSes are superior, which is that they somehow enable more democratic code development I think the point that was made was that the issue of commit access goes away : https://www.youtube.com/watch?v=4XpnKHJAok8&t=1139 https://www.youtube.com/watch?v=4XpnKHJAok8&t=1139 ( actually that whole talk is pretty interesting ). To be perfectly honest, most companies would do fine with subversion and a very good web based user interface. The simplicity and the advantage of not having to teach people set in their ways may work in its favor.