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?
Top comments (4)
That's not a typical workflow for centralized version control systems, and thus not SVN.
In SVN you check out the code (can be any path*), you make your changes, and you check them in. This is generally done with as little branching and merging as possible. Trunk based development is common practice.
*) in an SVN repo you can check out any path you desires. Commonly people organize their repo in:
/trunk/branch/*/tags/*But this is mostly an inheritance of CVS. You can check out
/trunk/foo/bar/quuxand just work on that. In quite a few cases SVN is used with a monorepo, for example ASF uses a monorepo for all SVN based projects.Thanks for the correction, trunk development sounds like a lot of pain imho. Is it really that hard to use branches in svn, and merge later on to trunk? What happens if you have 3 people working on different things working straight on the trunk?
People working on different branches and changing the same files (in those different branches) is a really really bad thing. And this is something svn only handles with manual merge conflict handling.
Key to successful development with a lot of people on a shared code base is continuous integration. Trunk based development is also an essential part of proper CI.
The born of git and mercurial was not because license changes in BitKeeper, but because someone tried to reverse engineer the BK protocol, that was against the license and authors of BitKeeper said that Linux Kernel violated the license and they no longer can use the product.
There is great talk at CodeMash (available on Plural Sight for free)
A Brief History of Version Control: CodeMash.