Exploring centralized vs. distributed systems

As mentioned in the section about history of Version Control, there are two different kinds of version control: Centralized, and Distributed. The workflow between these two different kinds are somewhat different, so I thought it would be worthwhile to go over the way in which these things are actually used from the point of view of a user using version control. So first, we'll talk about centralized version control. Typically, in centralized version control, a system admin creates the repository because the repository is always remote. Then you have your local working set, and you add or check in files to the remote repository, and you check out or revert files to update your working set.

Similarly, another user using a centralized version control system will connect up to the remote repository and have a different working set. They will check out your files and updates that you've made and add their own, and this goes back and forth in this check in/check-out update loop as you work with Version Control. But in this case, in Centralized Version Control, everything is kept in the remote repository. Now, some benefits of that are that the system administrator can then keep track of updates, can manage backups, can do system rollbacks for all the developers at once.

But it tends to be somewhat fragile, and it also tends to be problematic when you can't get access to the centralized server, if the server is down, if you're on an airplane, it becomes kind of cumbersome. So it depends on the magnitude of your project and the magnitude of your team, whether centralized version control is right for you, and we'll look back at that at the end of the course, looking at all the different Version Control Systems, and exploring how you can determine what's the right one to use for your particular project. Distributed Version Control works a little bit differently.

Typically, you initialize the repository because the repository is on your local box. Similar to the Centralized Version Control, you still have a working set, and you add things and you update them. In addition, you can also have this optional remote repository, which is a way of backing things up. Now typically, people that use Git or Mercurial use a system like this, and they will use a hosted system like GitHub in order to be able to back up their local repository into the cloud, and that's done as we mentioned just before in terminology by using push and pull.

Similarly, if that remote repository is not in the cloud but on another developer system, you would use import and export to send the data back and forth between the repositories. So that's a little bit of a look at the differences between centralized and distributed version control. Next, we are going to jump into all the concepts in more detail about getting things in, getting things out, how the process of history tracking works, and all of the information that you need to understand before we begin to look at specific version control implementations.