Before we begin using the modern Version Control Systems, a little bit of history is worth looking at. The first Version Control System was created in 1972 at Bell Labs where they developed UNIX. The first one was called SCCS. It was available only for UNIX and only worked with Source Code files. Ten years later the Revision Control System, or RCS, was developed, and it was the first cross-platform version control system, but once again, it was only for text files. Both SCCS and RCS only worked on the development system and were not for sharing code, as they only worked for a single user.
The next wave of Version Control Software-- what we call Centralized Version Control-- was developed starting in 1986. The Concurrent Versions System, or CVS, was the first one that had a central repository and was usable by multiple users. It was still file-focused and kept track of changes in individual files, as opposed to keeping track of changes in entire directory trees. Later on in the 1980s, along came Perforce, and it was widely used during the .com era. It's still the biggest repository used inside Google.
In 2000, a new product called Subversion was created and supported non-text files, tracking directory structure changes, such as file renames and moves, and its transaction unit was the directory as opposed to an individual file. So you could check in an entire directory tree and check it out. In 2004, Microsoft created the Team Foundation Server to replace its aging Visual SourceSafe Version Control System, which was primarily a client server system. TFS comes with an MSDN subscription, which means it's fairly expensive.
But it also has a TFS Express edition which is usable for up to I believe 5 users. TFS has tight Visual Studio integration. That means you can check in and check out right from inside Visual Studio. It supports not only source code control, but also has bug and work item tracking and features for doing automated testing. The next generation of source code control software is called Distributed Source Code Control. Distributed Source Code Control is different in that there's not a central server that everybody shares. Everybody shares their own individual repository and then can share their changes with a central server or share their changes with individual users.
Distributed Source Code Control came about because of a change in licensing from a company called BitKeeper. Previously, they had a product which was used by Linus Torvalds and the kernel group on Linux that was called the Community Edition, and it was free. But in 2005, BitKeeper decided to make its entire product line commercial only, meaning you had to pay a fee for using it, and Linus decided that he wanted to make sure that everything around Linux was free, and so he created something called Git. It's broadly used in conjunction with something called GitHub which is an online cloud-based service which offers free hosting for open-source projects and also commercial hosting for private use.
A competing product Mercurial was also created in 2005 in response to the same BitKeeper change and is also widely used in open source projects. That's a short history of Version Control from 1972 to 2012. These days, pretty much everybody uses one of five systems, Perforce, Subversion, or TFS if they want a centralized system, Git or Mercurial if they want a distributed system. And now that we have looked at the history, let's move on to looking at a little bit more details about the terminology that we need to understand, and a walk-through about how centralized and distributed systems work.
- Comparing centralized vs. distributed systems
- Saving changes and tracking history
- Using revert or rollback
- Working with the GUI tools
- Using IDE and shell integration
- Installing different systems
- Creating a repository
- Tagging code
- Branching and merging code
- Selecting a software version control system that's right for you