History of Version Control Systems VCS

I found myself reading a copy of The Architecture of Open Source Applications Vol II a particular topic opened my interest in learning how Git was designed and maybe I'll do another article on that alone. BitKeeper initially was giving free licensing to linux developers. At some point they started to revoke licenses for some linux kernel devs, and Linus built git out of necessity not being able to find anything that was a good fit for linux. In a way we can all thank BitMover for making that move.

In this article we will discuss some of the major players in VCS throughout history, and discuss some key features of each system. I will not be covering front end systems like Github, or Bitbucket but rather the backend models, git, mercurial, etc. By the way if there are any users of these legacy systems I'd like to hear about your experience.

Reasons to use VCS

Before getting started with the article, let's discuss why would someone would benefit from using such of system. Most of these systems can be implemented in a local server, and across the internet.

• File versioning
• Check-in / Check-out
• Branching
• Merging
• Multiple users working on a project
• and just a myriad of other benefits

Source Code Control System SCCS

One of the early vc systems for Unix, developed in 1972 by none other than Bell Labs. It was originally written in SNOBOL4, and then later rewritten in C by Marc Rochkind. The system was based on binary file formats single user, and version 4 was text based. SCCS Docs

Commands:

• Create - Creates a new history file, version on how many lines of code.
• Edit - Edits history file, sorta like commit.
• Delget - Check in new version, and updates history file, sorta like push.
• Get - Outputs version, and lines
• Prt - A full report on the file

It is worth noting that SCCS pretty much went obsolete when Centralized Systems became widespread.

Revision Control System RCS

RCS initial release was in 1982 by Walter F. Tichy at Purdue University. The system was text based, also written in C. The system was designed for Unix, but some people succeded in porting to other systems. The homepage has the latest tarball, and latest zip file for Win95 NT if you're into that sort of thing. RCS homepage Online Manual

• co - Checkout the file
• ci - Check in file
• rcs - Change rcs file attibutes
• ident - Extract identification markers
• rcsclean - remove unchanged working files
• rcsdiff - compare revisions
• rcsfreeze - record a configuration
• rcsmerge - merge revisions
• rlog - read log messages and other rcs file information

Concurrent Version Control CVS

Mid 80's saw a change in version control systems. CVS uses client-server architecture a centralized system. Dick Grune developed CSV in 1984-1985 as a front end to RCS mainly because RCS did not work with entire projects. CSV was built as a necessity since Grune needed to work on projects on his own time, while his students contributed on the same project. The system could be setup in a LAN, or across the galaxy with the help of internet connection.

A major feature in CVS system was the ability for multiple people to work on a single project without causing major conflicts. I've never used CVS myself but according to its creator merge conflicts were rare due to rcsmerge (RCS) doing a good job, and UpdateVersion which is sort of like pull.

• CreateVersion - Copies files into the repository as a private copy
• Commit - commit changes to the repository
• UpdateVersion - updates user files to the latest version

Subversion SVN

SVN is also a centralized system, the workflow for a user looks pretty similar to GIT with some term differences, and of course GIT is distributed more on that later. The workflow is something like this, create a branch from the trunk (Trunk is like the master if you are a git user), make changes then merge back to trunk. The branching model does differ from GIT, and makes it harder to merge when conflicts arise.

• list - see content of svn repository
• checkout - creates a working copy, of a file, directory, trunk or whole project.
• commit - commit changes to the server
• add - add file to the working copy, and the use commit to add to server
• delete - delete works same as add
• update - bring changes from repository to working copy
• status - status of working copy
• diff - find differences between working copy, and copy in the server, or two paths
• log - displays all commits made to file or directory
• move - rename file or directory

Distributed Systems

In 2005 shortly after BitKeeper licensing changed, two systems started being developed. Git by Linus and Mercurial by Matt Mackall. The Linux kernel project decided to go with git, for obvious reasons and the rest is history. Git holds a major market share 80% and mercurial 2% so you be the judge.

Both are available on most major OSes, Mac, Linux, and Windows. I presumed a good portion of dev.to users use git, but if you don't please comment below what you use.

What are some of the things you like/dislike about vcs?