Ytukyg

Whilst watching a tutorial on Lynda.com regarding Distributed Version Control Systems vs Centralized Version Control Systems, I came across some text which confused me on how Git tracks differently than the Centralized Version Control Systems. I always thought the mentioned VCS were tracking changes and when commiting you are saving the snapshot of these changes to the repository which is used to get from version-to-version. But for some reason the following text claims that Git doesn't work this way.

Can anyone try to explain and clearify this for me?

In Git the changes are stored as change sets or patches, and we're focused on tracking changes not the versions of the document. Now that's a subtle difference, you may think, well, CVS and SVN those track changes too, they don't. They track the changes that it takes to get from version-to-version of each of the different files or the different states of a directory. Git doesn't work that way, Git really focuses on these change sets in encapsulating a change set as a discrete unit and then those change sets can be exchanged between repositories. We're not trying to keep up-to-date with the latest version of something instead the question is, do we have a change set applied or not?

This tutorial is terribly wrong:

1. Git does not store changesets. Git computes changesets, dynamically, upon request. (Git does do delta-compression inside pack files, but pack files are fairly well hidden, compared to Git's object storage model, which is deliberately exposed through hash IDs.)


2. That's not a useful distinction when discussing distributed vs centralized. (See kan's answer as well.)

Here is what I have to say about distributed vs centralized in my own book:

The key difference between these two kinds of systems is that a centralized VCS has a designated master repository. There may be multiple copies of the master, or even multiple masters with some kind of synchronization protocol (e.g., ClearCase MultiSite), but there is only one master. Their design assumes this single-master-ship and thus is allowed to depend on it.

With a distributed VCS, there is no designated master repository. Users generally have a complete, private copy of each repository. Communications between these private copies are, at least in principle, peer-to-peer operations: neither repository is any more masterful, and conflicts—situations where both Alice and Bob have made changes to the same regions of the same files—can and do occur and require some kind of resolution.

It’s always possible to use a distributed VCS in a centralized manner: you simply designate one particular repository as the master version, and coordinate updates to it. However, centralized systems often provide features like locking source files or directories, restricting access (for read and/or write, to particular files, directories, and/or branches), and so on. With a typical DVCS it’s more difficult (though not technically impossible) to provide these, and Git and Mercurial simply don’t, at least not without add-ons. With CVCSes that provide locking, users may lock files (typically just one specific version ID) to prevent other users from making conflicting changes. This is conceptually easier, but of course it can prohibit parallel work.

In CVCS changes are syncronised around single central repository. So, commiting a change a user creates a single version in that repository for others.

While in DVCS each user has it's own independent copy of repository and all changesets (or commits) go here initially. There is a separate process of synching changes between other user repositories using fetch/push commands.