Earlier this year, we covered what a version control system is and why it is important. The first step in working with a VCS is determining which type to use. In this article, we will give a high-level overview of the different kinds of version control systems and how they work.
Local Version Control Systems
The most basic VCS is a local version control system. In this type of system, a database is created on a single computer. That database tracks a set of files and their changes over time. Each time the files are changed, a patch is pushed to the database. These patches will only contain the differences between the file and its most recent version. Want to see what a file looked like at a particular point in time? Combine all the patches from the file’s creation to that point in time, and you’ll get what the file looked like at that particular moment.
Pros:
Simple, Easy to Understand
Tracks Changes Over Time
Cons:
Single Point of Failure – If anything happens to the machine the VCS is stored on, everything is lost. Additionally, if any patches are lost or corrupted, all the changes after that version are rendered moot.
Poor Collaboration – Since a Local VCS is only on one machine, collaboration with multiple people is effectively impossible.
Centralized Version Control Systems
A centralized version control system, or CVCS, is a much better solution when working collaboratively. In a CVCS, a repository (a database tracking changes to a file set) sits on a server. Multiple people can pull the files from the server to their local machines to work with simultaneously. When users are ready to share their changes, all they have to do is push the changes from their local machine back to the server. Then, anyone working on the project can pull down the update and have the most up-to-date version of the file set. A typical example of centralized version control systems is Team Foundation Version Control (TFVC).
Pros:
Tracks Changes Over Time
Enables Collaboration – Multiple users can work with the same files concurrently.
Administrative Control – Admins determine who can edit the files and push updates to the repository and who can only pull the files to their local machine for review.
Cons:
Susceptible to Failure – Because there is only one database on a centralized server, a CVCS is still susceptible to failure. If something happens to that server or the database, none of the users can pull files to their machine or push any updates. In this situation, the history of the file set would be gone. The only salvageable pieces would be the copies any users may have copied to their machines, but those would only be single sets – not the history of the project as a whole.
Distributed Version Control Systems
Like in a CVCS, a distributed version control system, or DVCS, has a repository. However, when someone pulls a copy of the files to their machine, a DVCS will also send the complete history of the file set. The user will get a local copy of the repository, with all its changes over time. Suppose the original server holding the repository goes down temporarily. In that case, anyone working on the project can still make new snapshots of their file set and add them to their local repository. When the server comes back online, they can push all of their changes back up. If the server goes down permanently, anyone who has a copy of the project has its entire history, so everything is salvageable.
Additionally, users working with a DVCS can send snapshots of the files back and forth since they each have a copy of the repository with all its changes. The local copies of the snapshot will combine these copies in the same way the centralized server would. Common examples of a DVCS are GIT (which we use at GEO Jobe) and Mecurial.
Pros:
Tracks Changes Over Time
Enables Collaboration
Administrative Control
Complete Version Copying – Each machine that gets a copy of the file set receives a copy of its entire history in the database as well.
Cons:
More Steps for Sharing Updates – To share your changes with others, you have to commit your changes to your local repository and push your local repository to merge with a centralized repository. Anyone who wants a copy of your changes then has to pull those changes to their machine and update their repository.
What’s Next?
Do you use a version control system? If so, what type of system? If not, what kind do you think your work could benefit from? Let us know on Twitter or via e-mail. Want to know more? Check out the start of this series here. You can also subscribe to our blog to get notified when future articles come out.
